This is a bit more information regarding what out of band data really is.
Source: UNIX Network Programming by W. Richard Stevens.
All this gets more complicated with TCP becuase it can send the notification that out-of-band data exists (termed "urgent data" by TCP) before it sends the out-of-band data. In this case, if the process executes one of the three receive system calls, an error of EWOULDBLOCK is returned if the out-of-band data has not arrived. As with the SPP example above [which I have not included on this page], an error of EINVAL is returned by these three system calls if the MSG_OOB flag is specified when there isn't any out-of-band data.
Still another option is provided with the TCP implementation, to allow for multiple bytes of out-of-band data. By default, only a single byte of out-of-band data is provided, and unlike SPP, this byte of data is not stored in the normal data stream. This data byte can only be read by specifying the MSG_OOB flag to the receive system calls. But if we set the SO_OOBINLINE option for the socket, using the setsockopt system call described in Section 6.11, the out-of-band data is left in the normal data stream and is read without specifying the MSG_OOB flag. If this socket option is enabled, we must use the SIOCATMARK ioctl to determine where in the data stream the out-of-band data occurs. In this case, if multiple occurrences of out-of-band data are received, all the data is left in-line (i.e, none of the data can be lost) but the mark returned by the SIOCATMARK ioctl corresponds to the final sequence of out-of-band data that was received. If the out-of-band data is not received in-line, it is possible to lose some intermediate out-of-band data when the out-of-band data arrives faster that it is processed by the user.