Symbian OS Communications (779884), страница 44
Текст из файла (страница 44)
Since the IP address is shared between the primaryand secondary contexts, an RSubConnection uses the same networkinterface and IAP as its parent RConnection.The QoS parameters are negotiated with the network – the applicationcan provide two sets of parameters, the requested set and the minimumacceptable. The network will then either allocate the QoS in the range ofthe requested and minimum acceptable, or it will reject the request.
Thisis done asynchronously, so the application must determine whether theQoS has been accepted using the event notification methods described alittle later. But first, the configuration of the QoS parameters is discussed.To create an explicit subconnection, there must first be a primary PDPcontext active via the parent RConnection. Then the subconnectioncan be opened:RSubConnection iSubConn; // class member...err = iSubConn.Open(iSockServ, ECreateNew, iConn);QUALITY OF SERVICERConnectionPrimary PDP Context199GGSNSecondary PDPcontextRSubConnectionAdd parameters()RSubConParameterBundleCSubConParameterFamilyCSubQosGenericSetCSubCon QoSR99PameterSet...SetTrafficClass() etc.SetBandwidth()SetDelay()...Figure 6.10Setting QoS parameters on a subconnectionThis associates the subconnection with the active network connectionand an existing IP address.
The application then needs to set the QoSparameters it requires from the network. This is done by creating anRSubConParameterBundle and filling it with the correct parameters.There are different sets of parameters that can be used – a generic set, i.e.one that is not specific to the bearer being used, or a bearer specific set(in this case, 3G). The different parameters are added to the RSubConParameterBundle using a container CSubConParameterFamily,which in turn has the generic and 3G QoS parameters added to it.The generic QoS parameters are represented by the CSubConQosGenericParamSet and the 3G QoS parameters are represented by theCSubConQosR99ParamSet.Generic QoS parametersThe generic QoS parameters allow the application to request thefollowing:ParameterDescriptionBandwidthBandwidth the client requiresMaximum burst sizeMaximum size of a burst of data theclient can handle200IP AND RELATED TECHNOLOGIESParameterDescriptionAverage packet sizeAverage packet size required (e.g.codec use)Maximum packet sizeMaximum packet size the client canhandleDelayAcceptable delay/latencyDelay variationAcceptable variation in delay (alsoknown as jitter)PriorityRelative priority the client expects togive this channel compared to itsother channelsHeader modeSpecify whether the header sizeshould be calculated by the QoSmodule or specified by the client.Default is to let the QoS modulecalculate itNameIdentity of a ‘well-known’ set of QoSparametersSo to create a generic set of QoS parameters:RSubConParameterBundle paramBundle;// Create the container objectCSubConParameterFamily* qosFamily =CSubConParameterFamily::NewL(paramBundle, KSubConQoSFamily);// Create the minimum accepted and request parameter setsCSubConQosGenericParamSet* genericMinParams =CSubConQosGenericParamSet::NewL(qosFamily,CSubConParameterFamily::EAcceptable);genericParams->SetDownlinkBandwidth(128);genericParams->SetDownLinkDelay(64);CSubConQosGenericParamSet* genericRequestedParams =CSubConQosGenericParamSet::NewL(qosFamily,CSubConParameterFamily::ERequested);genericParams->SetDownlinkBandwidth(128);genericParams->SetDownLinkDelay(64);The RSubConParameterBundle now takes ownership of the CSubConParameterFamily so the client does not need to delete it later.If only the generic set of parameters is requested, the system will makea best-effort mapping to the 3G QoS settings.
However, in some cases,QUALITY OF SERVICE201the application may be better placed to set the 3G QoS parameters itself,although this will obviously mean that further changes are necessary asfurther QoS-aware bearers are introduced in the future.3G QoS parametersThe 3G QoS parameters are handled in a very similar way to thegeneric set, but using the CSubConQosR99ParamSet. This allows all ofthe QoS parameters as defined in 3GPP 23.107 to be configured by theapplication. The parameters are mapped directly onto the QoS parametersdefined in the Symbian telephony API, RPacketQoS, therefore see thedocumentation of RPacketQoS for more details.// Create the minimum accepted and requested 3G parameter setsCSubConQosR99ParamSet* minParams = CSubConQosR99ParamSet::NewL(qosFamily,CSubConParameterFamily::EAcceptable);minParams->SetTrafficClass (EStreaming);minParams->SetMaxBitrateDownlink (256);CSubConQosR99ParamSet* requestedParams =CSubConQosR99ParamSet::NewL(qosFamily,CSubConParameterFamily::ERequested);requestedParams->SetTrafficClass(EStreaming);requestedParams->SetMaxBitrateDownlink(128);These parameters can now be added to the subconnection:TInt err = iSubconn.SetParameters(paramBundle);It is also possible to use the SetGenericSetL() and AddExtensionSetL() methods to add the parameter sets to the CSubConParameterFamily instead of using the version of CSubConQosGenericParamSet::NewL() which does it implicitly.RSubConParameterBundle paramBundle;// Create the container objectCSubConParameterFamily* qosFamily =CSubConParameterFamily::NewL(paramBundle, KSubConQoSFamily);CSubConQosGenericParamSet* genericMinParams =CSubConQosGenericParamSet::NewL();genericMinParams-> SetDownlinkBandwidth(128); // WHAT UNITS ARE THESE IN?genericParams-> SetDownLinkDelay(64); // WHAT UNITS ARE THESE IN?qosFamily.SetGenericSetL(genericMinParams,CSubConParameterFamily::ERequested);Event notificationsThe application must listen for QoS event notifications to determinewhether the QoS has been accepted by the network before continuingwith data transfer on the subconnection:202IP AND RELATED TECHNOLOGIESiSubconn.EventNotification(iNotifBuf,ETrue,iStatus);This completes when one of the following events occurs:CSubConGenEventParamsGrantedQoS negotiation with the network has been completed successfully.The application can then retrieve the negotiated QoS parameters arefrom the CSubConParameterFamily, which will be somewhere between the requested and minimum acceptable.CSubConGenericParameterSet* negotiatedQoS =qosFamily.GetGenericSet(CSubConParameterFamily::EGranted);orCSubConQosR99ParamSet * negotiatedQoS =qosFamily.GetExtensionSet(KSubConQosR99ParamsType ,CSubConParameterFamily::EGranted);CSubConGenEventParamsRejectedQoS negotiation with the network has failed – the network wouldnot allocate the QoS requested.
The secondary PDP context has notbeen activated. The reason for the failure can be determined using theError() method.CSubConGenEventParamsChangedThe QoS has been renegotiated due to some event on the network. Thisevent is triggered by the network, not by a request sent by the application.CSubConGenEventSubConDownThe subconnection has been lost, that is, the secondary PDP contexthas been terminated. This could be initiated from the device closing theconnection, or by the network if an error occurs.
The actual error can bedetermined using the Error() method.CSubConGenEventDataClientJoinedA socket has been added to the subconnection. See ‘Adding sockets toa subconnection’ below.CSubConGenEventDataClientLeftSUMMARY203A socket has been removed from the subconnection. See ‘Addingsockets to a subconnection’ below.If the network does not allocate the requested QoS settings, then thenecessary channel characteristics cannot be guaranteed. The applicationdeveloper then needs to make a decision on whether to continue using theparent RConnection object, that is, using the default QoS parameters.In this case, the application will have to handle any problems causedby the incorrect QoS settings, such as buffering data if it isn’t receivedquickly enough.Adding sockets to a subconnectionOnce the subconnection is active, data can be sent over it by attaching sockets to it. All data transferred using the attached sockets willthen use the secondary PDP context.
There are two possible ways ofdoing this:1. Open the socket using RSubConnection instead of RConnection:TInt err = iSock.Open(iSockServ, KAfInet, KSockStream, KProtocolInetTcp,iSubconn);2. Adding an existing socket to the subconnection (in this case, thesubconnection must be related to the parent connection used toopen the socket originally):iSubconn.Add(iSock, iStatus);Note that any errors relating to the network/secondary PDP context/QoS will be returned via the event notifications. Other errors returnedwill be programming or system errors relating only to the immediateoperation. This is handled asynchronously since interaction with thenetwork is required (the device has to give information to the network to allow it to route that socket’s data over the secondary PDPcontext). When the socket has been successfully added (or removedusing Remove()), the CSubConGenEventDataClientJoining (orCSubConGenEventDataClientLeaving) events described earlier arenotified.6.7 SummaryIn this chapter, we have learnt how to:• select a specific connection for our application to use, or get thesystem to prompt the user on our behalf204IP AND RELATED TECHNOLOGIES• monitor the progress of a connection as it is started and stopped sowe can provide feedback to the user• perform DNS lookups to map DNS names to IP addresses• use TCP and UDP sockets• use TLS over a TCP socket• configure QoS on 3G networks.7Telephony in Symbian OSThe telephony subsystem is the interface to the cellular network functionality in the phone.
As we mentioned in Chapter 2, this is sourced by thephone manufacturer and typically runs on a different OS and differentprocessor core to Symbian OS. In practice, it is the gateway to the servicesprovided by your network operator – both voice and data.The telephony subsystem provides support for W-CDMA (3GPP R4and R5), GSM circuit-switched voice and data (CSD and EDGE CSD)and packet-switched data (GPRS and EDGE GPRS). In addition, thereis also support for CDMA circuit-switched voice and data, and packetswitched data (IS-95 and 1xRTT), although there are no phones supportingthis standard on the market. Access to the SIM, RUIM or UICC is alsoprovided.The main purpose of the telephony APIs are to provide access to thecellular network.
The type of access provided can be divided into twocategories – data-centric or voice-centric.Data-centric applications will typically access the phone networkthrough higher level APIs rather than those provided by ETel – in particular, they will use the ESOCK APIs such as RConnection to createconnections to the cellular network, in the same way as they would forother types of network, then RSocket to transfer data over that connection. This abstracts the details of creating a connection over the cellularnetwork away from the application, as the interface to ETel is handled bythe networking subsystem, and the connection made using informationfrom the communications database (Commsdat).Voice-centric applications are typically the ones that handle voicecalls, including placing an outgoing call or answering an incoming one.They may also make the use of Supplementary Services such as callbarring and forwarding.
Voice-centric applications use the telephonysubsystem directly, rather than using a higher-level API.206TELEPHONY IN SYMBIAN OSTelephony APIs also provide access to information contained on theSIM card, such as the IMSI number; on the device, such as the IMEI; orfrom the network, such as the ID of the cell in which we are located.In order to provide access to this functionality, a restricted set of APIsis offered via a component called ETel ISV, which is also known as ‘ETel3rd Party’.
We will explain how to use this API and provide an exampleapplication, as well as documenting the precautions that must be takenwhen using these APIs, along with their limitations.There are other components that form part of the telephony subsystemthat we will omit from this chapter, as they do not expose APIs fordevelopers – in particular, the phonebook synchronizer, which is onlydistributed as part of UIQ.VOIP Calls cannot be established using Etel ISV please refer to theSIP/RTP chapters.7.1 OverviewFigure 7.1 shows a high-level overview of the telephony subsystem andits major functional blocks, as well as the main interfaces betweencomponents.Data appESockNative PhoneappNetworking subsystemVoice andinfo appETEL ISVPacket ETelMultimode ETelKeyETEL ServerData flowControl flowTSY3rd partyBasebandNot implemented in Symbian OSFigure 7.1 Telephony subsystemSymbianManufacturerUSING THE ETEL ISV API2077.2 Using the ETel ISV APIAs part of the example applications, we will show two major areas forwhich you may wish to use the ETel ISV API.The first is making outgoing phone calls.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
