Hi Fred, > When initiating a transparent eSCO connection, make use of T2 settings at > first try. T2 is the recommended settings from HFP 1.6 WideBand Speech. Upon > connection failure, try T1 settings. > > When CVSD is requested and eSCO is supported, try to establish eSCO connection > using S3 settings. If it fails, fallback in sequence to S2, S1, D1, D0 settings. > > Failure is detected if Synchronous Connection Complete event fails with > error 0x0d. This error code has been found experimentally by sending a T2 > request to a T1 only SCO listener. It means "Connection Rejected due to > Limited resource". > To know which setting should be used, conn->fallback is used. Bluez only > attempt to reconnect twice. Since, more than 2 fallback are required, > conn->fallback is tested as an alternative measure. We want to fallback only if > conn->fallback is positive. Calling hci_setup_sync with conn->fallback == 0 > triggers initial connection attempt. > > These setting and the fallback order are described in Bluetooth HFP 1.6 > specification p. 101. before we do the fallback handling, lets get the basic CVSD vs transparent work done properly. The one thing that I am missing is the handling of SCO/eSCO setup error handling. Like say when using connect() and we try to establish transparent link where not available. Or accept() with defer setup and the transparent link does not work out. The fallback handling can be a separate patch once the others are all in a mergable state. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
