Symbian OS Communications (779884), страница 27
Текст из файла (страница 27)
The application knowsthe structure of the remote SDP record since the record is definedand published by itself. So, it asserts that the only attribute that isa DES is the ProtocolDescriptorList. Then it can proceed to interpretthe ProtocolDescriptorList to find the dynamic L2CAP PSM (again, theapplication knows that the service is running on L2CAP, not, for example,RFCOMM. This compromises the ability to change the SDP record. Itis recommended that services fully parse the ProtocolDescriptorList sothat the new versions of the service can easily be deployed, or consultversioning attributes of your SDP record).Here is the code which begins parsing the ProtocolDescriptorList:if (aAttrValue.Type()==ETypeDES){ASSERT(iAttributeToParse==KSdpAttrIdProtocolDescriptorList);// not expecting any DEAs in the record/attribute set we asked for//static_cast<CSdpAttrValueDES&>(aAttrValue).AcceptVisitorL( *this);}The visitor to the attribute operates synchronously, and will call backMSdpAttributeValueVisitor::VisitAttributeValueL()EXAMPLE SYMBIAN OS BLUETOOTH APPLICATION117when each value in the list has been visited.
In the example the methodthat implements this callback is as follows:// to check that we have coded to our design correctlyASSERT(iAttributeToParse==KSdpAttrIdProtocolDescriptorList);if ((aType == ETypeUUID) && (aValue.UUID() == TUUID(KL2CAPUUID))){iL2CAPFound = ETrue;}if ((aType == ETypeUint) && iL2CAPFound){// here’s the l2cap port!// iPSM is a member variable so that we can pass the value out of this// visiting loopiPSM = aValue.Uint();}After the ‘visitation’ of the ProtocolDescriptorList is complete, the iPSMvalue can be put into a TL2CAPSockAddr, along with the Bluetoothdevice address.
This can then be given to the part of the exampleapplication that connects L2CAP sockets:if (iL2CAPFound){TL2CAPSockAddr l2Addr;l2Addr.SetBTAddr(aRemoteDevice);l2Addr.SetPort(iPSM);iNotify->MshnDeviceFound(l2Addr);}4.3.6 Sockets in the Example CodeThe example code makes extensive use of CBluetoothSocket: it showshow they can be connected, how to transfer data, and how to performphysical-link level role switching.One shortcoming of the CBluetoothSocket class is that if thereexists a class that wishes to own two or more of them (as the CBluetoothBusEngine class does), then in the context of a MBluetoothSocketNotifier callback from the CBluetoothSocket, the owningclass will not be able to deduce which of the sockets is calling itback.To solve this problem the example code inserts a new class, CIdentifiableSocket, between the owning class and the CBluetoothSocket, and publishes a new mixin, MIdentifiableBluetoothSocketNotifier, to replace the MBluetoothSocketNotifier.The CIdentifiableSocket implements the regular MBluetoothSocketNotifier; so for each callback from MBluetoothSocketNotifier it forwards the call to MIdentifiableBluetoothSocketNotifier but with a reference to itself.
This enables the owner of a118BLUETOOTHnumber of CIdentifiableSockets to deduce the source of a notification. The CIdentifiableSocket also provides a simple gettermethod to enable the client to access the CBluetoothSocket forthe purpose of calling the regular CBluetoothSocket methods (itwould perhaps have been preferable to provide forwarding functions onCIdentifiableSocket).4.3.7 Other Design PointsWithin the bus transport layer the state pattern is used to reflect thedifferent states of the uplink and downlink.The role switches are made in a ‘prospective’ manner; that is if theydon’t work then the code will not raise an error – it will continue toprovide a service, but possibly the service is not optimized.
The roleswitch is sought so that the device tries to ‘scatternet’ – that is be a masterand a slave at the same time. When the ‘downstream’ socket is connected,the physical link over which the socket runs is requested to be masterat the local device. Conversely, when the ‘upstream’ socket is connected,the physical link over which that socket runs is requested to be slave atthe local device:void CInfiniBTEngine::DoDownstreamConnectionComplete(TBoolaUpstreamPresent).
. ..(void)iDownstream->Socket().RequestMasterRole(); //ignore error...void CInfiniBTEngine::DoUpstreamConnectionComplete(TBoolaDownstreamPresent)...(void)iUpstream->Socket().RequestSlaveRole(); //ignore error4.4 AV Protocols and ProfilesThis section includes a brief discussion about the AV protocols in Bluetooth; even though direct interfaces to the protocols are not providedin Symbian OS. However, the profiles they support can be used viahigh-level abstraction APIs.The audio video control transport protocol (AVCTP) is a message-basedprotocol that encapsulates media-control frames into L2CAP packets. Itprovides a fragmentation service to the upper layer so that the higherlayer packets can be split over the potentially smaller L2CAP packets.
Thefragmented frames are reassembled at the receiving AVCTP entity beforepassing to the upper layer. In effect it is hiding the L2CAP packet sizefrom the layer above AVCTP; thus enabling a legacy implementation of amedia-control protocol to not need to be changed to fragment its packets.The audio video remote control profile (AVRCP) is the only Bluetoothprofile that specifies use of AVCTP at present. AVCTP also provides aAV PROTOCOLS AND PROFILES119limited multiplexing service, so in future other profiles relating to mediacontrol can coexist over the same L2CAP channel. AVRCP captures in aBluetooth specification the use cases of a user controlling a media devicesuch as a TV, CD player or amplifier: those use cases that are currentlydominated by proprietary infrared remote control devices.
In the future itis to be hoped that more consumer electronic devices will use Bluetoothfor their control needs: this would open up the compelling possibility ofusing a Symbian OS device to present a remote control user interface ofthe user’s choice, and allow, for example, auto-muting when a phonecall arrives.AVRCP takes advantage of the services of AVCTP, to run an existingmedia-control protocol via Bluetooth. The media-control protocol specified is a subset of the AV/C protocol that was originally designed tobe transported over Firewire (a wired technology that is often used totransport AV data, and control the devices supplying or consuming thedata). AVRCP defines a device that is sending an AVRCP command asa ‘controller’, and the receiver of such a command as a ‘target’.
AV/Cmodels an AV device as being constituted of a ‘unit’ that comprises anumber of ‘subunits’. Each subunit might be for example, a tuner, amixer or an amplifier. There is also one more subunit in an AV/C unitthat is key to the AVRCP subset of AV/C – that is the ‘panel’ subunit. Inversion 1.0 of the AVRCP specification, all commands are sent to thepanel subunit. However, the commands that are sent are actually knownas ‘passthrough’ commands: it is therefore up to the panel subunit in the‘target’ device to route the command to the correct logical subunit. Thissimplifies the task of the AVRCP controller as it does not have to find outthe addressing details of all of the subunits in the target.For the distribution of AV data itself (rather than the explicit userlevel control of the media device), the audio video distribution transportprotocol is used.
AVDTP, which runs over L2CAP, is both a signallingprotocol (in the control plane) and a multiplexing datagram protocol (inthe user plane). It is the key protocol used when streaming AV media – itdiscovers what codecs are available on a remote device, whether theyare available and what the codec capabilities are. AVDTP can then beused to negotiate bitrates and other settings that optimize the streamingperformance.
Finally AVDTP is used for starting and suspending therunning of the remote codec; and also to close codec connections.The generic audio video distribution profile (GAVDP) is a specificationthat adds details about how AVDTP is used to support AV streaming usecases. It is an ‘abstract’ profile that does not yield concrete use cases;although it does yield an API in Symbian OS that licensees can use toimplement audio or video streaming (the advanced audio distributionand video distribution profiles, respectively). The licensee may elect toadd another interface onto the GAVDP interface in Symbian OS so thatdevelopers can develop GAVDP-based profiles themselves; however,120BLUETOOTHshipped as standard, only Symbian partners can develop against theGAVDP API.The A2DP profile specifies a mandatory codec to support in allBluetooth devices claiming to support A2DP; it also specifies that thecodec data be transported via RTP and AVDTP.
This is therefore not thatdissimilar to streaming over the Internet which typically has codec dataencapsulated in RTP packets, but which are transported via a layer-4transport datagram protocol (UDP). Of course, the benefit of A2DP is thatit recognizes that in most use cases of Bluetooth streaming there is no needfor the layer 3 or 4 protocols since the connection from source to sink ispoint-to-point. This demonstrates one of the clear benefits of Bluetoothprofiles: reuse existing technologies when appropriate, but introduceefficiencies as needed, and also introduce mandatory components so thatdevices have increased interoperability.
Note that the mandatory codec(‘SBC’) is not one of the more common audio codecs: this is to remove anyneed for codec licensing fees, and also to optimize the use of processingdevices in each Bluetooth device. The mandatory codec yields a higherbitrate for the same quality as other codecs, but requires less machineinstructions to operate – which leads to a reduced battery consumption.The video distribution profile (VDP) is very similar to A2DP, but withdifferent codecs specified.AVDTP also has a data-plane service that allows multiplexing ofAV data into more complex sets of L2CAP channels. Although this isimplemented in Symbian OS it is not currently used since no otherdevices currently support the feature.Notice that although AVDTP has a control-plane aspect, it differsfrom the service provided by AVCTP and AVRCP: the latter implementsthe user-level control, whereas the control plane of AVDTP is invisibleto the user, and is not directly used when a remote-control button ispressed.
Following from this, although it is often the case that a BluetoothAV device may have AVDTP and AVCTP implemented, this is not arequirement. For example, basic stereo Bluetooth headphones may notimplement AVRCP/AVCTP at all; yet another device may be purely aremote control, and thus not implement AVDTP.The two AV protocols of Bluetooth, AVDTP and AVCTP, are availablein Symbian OS from v9.1, but are not directly available for direct, generalapplication use. This is done for good reason: the use cases enabled bythese protocols imply that direct access to them is actually not useful forapplications. However, a framework for sending and receiving remotecontrol signals is provided that can be used by applications.For the distribution side of Bluetooth AV, no direct access to theseAPIs is presented.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
