RIL Incoming Voice Call Receiving Process (Windows Embedded CE 6.0)
1/6/2010
To receive an inbound voice call, the cellular TSP and the RIL driver complete the following steps:
The radio detects an incoming call.
RIL generates a RIL_NOTIFY_RING message with the following values set in the RILRINGINFO structure.
Member Value dwCallType
RIL_CALLTYPE_VOICE
dwAddressId
0
RIL generates a RIL_NOTIFY_CALLERID message with the following values set in the RILREMOTEPARTYINFO structure.
Member Value raAddress
"4255551212"
dwValidity
RIL_REMOTEPARTYINFO_VALID
TAPI calls the RIL_GetLineStatus function to obtain the status of the call. The return value should be RIL_RESULT_OK with the lpData parameter containing a pointer to the RIL_LINESTAT_RINGING constant. This step may occur multiple times.
Connection Manager requests that TAPI obtain the mute state by calling RIL_GetAudioMuting. The return value should be RIL_RESULT_OK - FALSE (not muted). This step may occur multiple times.
TAPI calls the RIL_GetCallList function to obtain a list of available calls. This step may occur multiple times. The return value should be RIL_RESULT_OK with the lpData parameter containing a pointer to RILCALLINFO with the following values set.
Member Value dwID
1
dwDirection
RIL_CALLDIR_INCOMING
dwStatus
RIL_CALLSTAT_INCOMING
dwType
RIL_CALLTYPE_VOICE
dwMultiparty
RIL_CALL_SINGLEPARTY
raAddress
"14255551212"
When the user answers the phone, TAPI calls RIL_Answer.
The radio answers the call.
The RIL driver returns RIL_RESULT_OK with lpData = NULL for the answer command.
The RIL driver generates the RIL_NOTIFY_CONNECT and RIL_CALLTYPE_VOICE constants.
The TSP calls RIL_SetAudioDevices to set RIL_AUDIO_HANDSET as the device for both Tx and Rx audio. The return value should be RIL_RESULT_OK.
TAPI calls the RIL_GetLineStatus function to make sure that the call has been answered. The return value should be RIL_RESULT_OK with the lpData parameter pointing to the RIL_LINESTAT_CALLINPROGRESS constant.
If an incoming call notification is received by Connection Manager via TAPI while a data connection is active, the Connection Manager will request a disconnect of the data connection and wait for a response from the radio that the data is appropriately disconnected before receiving the incoming call. The incoming call will not be received if the radio does not disconnect the data connection. If the data connection is capable of a suspend and resume, the radio should mark the data connection as suspended.
Under normal operation, if a voice call is being initiated, a lower priority connection cannot be initiated at the same time. But certain situations can occur when data connections are requested to the radio before the notification about an incoming call reaches the Connection Manager. In this case, the data connection is rejected in favor of the possible voice call if both connections cannot be connected concurrently. Another acceptable behavior would be to reject the voice call and connect data, but this might lead to poorer user experience.
Certain applications might also make connection requests directly to the radio, without going through the Connection Manager. If the requested connection uses radio resources, Connection Manager will detect those connections, and keep an internal fake connection object classified as an alien connection which has a higher priority than data connections and lower priority than other Connection Manager voice connections. Thus, if a voice call is requested, the alien call will be disconnected by Connection Manager, and the voice call will be made once the alien connection is detected to be disconnected.
Note
By default, simultaneous data and voice connections are not supported. This capability is enabled only if the RIL driver sends the RIL_NOTIFY_SYSTEMCAPSCHANGED notification set to RIL_SYSTEMCAPS_VOICEDATA.
Requirements
| Windows Embedded CE | Windows Embedded CE 6.0 and later |
See Also
Reference
Concepts
RIL Outgoing Voice Call Process