none
Incoming SCO connection in Bluetooth profile driver RRS feed

  • Question

  • Hi,

    I have written a Bluetooth driver to support read/write SCO data. It works fine when I am initiating outgoing SCO connections. But now I want to receive incoming SCO. I have registered my driver by BRB_SCO_REGISTER_SERVER, as it was explained in this article Accepting SCO Connections in a Bluetooth Profile Driver, but nothing happen! I do not receive ScoIndicationRemoteConnect indications and my registered callback function is not called at all!
    May be there are other preconditions exist in order to receive incoming SCO? E.g. the driver should register some records in SDP or must have special GUID when creating device interface (WdfDeviceCreateDeviceInterface)?
    Waiting for your advices, any help will be very appreciated.
    Thanks

    Thursday, August 15, 2013 4:18 PM

Answers

  • Hi Greg,

    many thanks for your help.

    It is funny, but I spent a few days for this stupid issue. My mistake was in that the brb->BtAddress should be remote device address, but I thought this is my local radio address. The L2CAP registration API permits BTH_ADDR_NULL in order to receive incoming requests from any device, but for some reason our colleagues from MSFT implemented the SCO without this capability. I have taken some commented out line from the Echo sample where it was the local address, without checking it in the documentation. Now I fixed it and all are working :)
    Thanks once more.

    Sergey
    Saturday, August 24, 2013 10:09 AM

All replies

  • Hi,

    Thanks for your question.  Can you elaborate on the parameters used when registering your SCO_SERVER and what/how (the device side) you expect the connection to be initiated?

    Thanks

    Thursday, August 15, 2013 8:27 PM
  • Thanks for your reply,

    I am writing Bluetooth Handsfree profile driver: part of it (RFCOMM + SDP) is live in user mode, but SCO channels live in the kernel mode.
    I have started from MSFT L2CAP driver sample (client + server, Bluetooth Echo L2CAP Profile Driver)and, because of its DDI interface is identical to the SCO interface, I expected that it will also work. When registering SCO server I am passing the following parameters:

    // Registers SCO server
    devCtx->Header.ProfileDrvInterface.BthReuseBrb(&(devCtx->RegisterUnregisterBrb), BRB_SCO_REGISTER_SERVER);
    
    brb = (struct _BRB_SCO_REGISTER_SERVER*) &(devCtx->RegisterUnregisterBrb);
    
    // Format BRB
    brb->BtAddress			= devCtx->Header.LocalBthAddr;
    brb->IndicationCallback		= &HfpSrvIndicationCallback;
    brb->IndicationCallbackContext	= devCtx;
    brb->IndicationFlags		= SCO_INDICATION_VALID_FLAGS;
    brb->ReferenceObject		= WdfDeviceWdmGetDeviceObject(devCtx->Header.Device);
    The devCtx->Header.LocalBthAddr is already initiated and is true my PC bth address. I am expecting that my driver will receive all incoming SCO requests when some device, no matter of which class, will send open SCO request to this PC Bluetooth Radio. Am I right or not?
    The code above is called from EvtDeviceSelfManagedIoInit (member of WDF_PNPPOWER_EVENT_CALLBACKS registered by EVT_WDF_DRIVER_DEVICE_ADD). Is it correct place to register the SCO server?

    Thanks once more,
    Sergey




    • Edited by RedSoftk Thursday, August 15, 2013 10:33 PM
    Thursday, August 15, 2013 9:51 PM
  • Hi Sergy,

    The answer is yes, that's how it should work.  Everything that you've shown looks just like mine except for the context.  I'm assuming that you've transplanted the code from the L2CAP server to the client (which is what I did).  The server keeps it's connection context in devCtx, but the client keeps it in the connection so I have Connection instead of devCtx.   My version is working just as you described.  I provide the bth address of the phone I'm want to allow to connect.

    As for where to call it from, I think you need to at least have your connection created and initialized first.  If you do it that early then you ought to be able to call it then.

    Are you getting a good status back from the BRB call?  I'm guessing you are sending via SendBrbSynchornously?  Seems like you should at least be getting an error.

    Greg

    Thursday, August 22, 2013 8:01 PM
  • Hi Greg,

    many thanks for your help.

    It is funny, but I spent a few days for this stupid issue. My mistake was in that the brb->BtAddress should be remote device address, but I thought this is my local radio address. The L2CAP registration API permits BTH_ADDR_NULL in order to receive incoming requests from any device, but for some reason our colleagues from MSFT implemented the SCO without this capability. I have taken some commented out line from the Echo sample where it was the local address, without checking it in the documentation. Now I fixed it and all are working :)
    Thanks once more.

    Sergey
    Saturday, August 24, 2013 10:09 AM
  • Ahh, I see that now in the code  block you provided.  Sorry I didn't pick that up!

    Greg

    Monday, August 26, 2013 4:18 PM
  • Hi,

    I started writing bluetooth profile driver for reading/writing sco data.

    Can you please explain how to achieve this?

    Is there any link?

    How to read rfcomm data? i mean AT commands?

    Do we need to create virtual sound devices or i need to write MIC data to Bluetooth sco write function and the sco data from bluetooth i need to write into speaker?

    Thanks.

    Monday, October 27, 2014 6:07 PM