Radio Interface Layer Changes for Suspend and Resume
The following list shows the changes required in the Radio Interface Layer (RIL) for CDMA to support the suspend and resume feature.
RIL_GetCallList will report two calls when in a 1xRTT call and a voice call. Each call will have a unique dwID in the RILCALLINFO.
RIL will be able to end either call, using the unique dwID through the RIL_CALLCMD_RELEASECALL command in RIL_ManageCalls.
When a voice call comes in during a 1xRTT call, RIL_GetLineStatus must return RIL_LINESTAT_RINGING and a RIL_NOTIFY_RING notification should be sent.
RIL should return RIL_E_LINKRESERVED when a voice call fails due to an active data call.
Although the connection is kept active during the voice call, it is not reachable. No data can be sent or received on this data connection during the voice call.
Incoming voice call notifications can be received only if there is no traffic over the packet connection at the time the call is made. If data is being actively transferred over the packet connection, such as when a user is listening to streaming media, incoming call notifications will not be received. If the packet connection is established but there are no packets being sent or received, the user will receive incoming call notifications.
If the user manually disconnects the packet connection using the disconnect button in the connection bubble, the packet data connection will remain disconnected until the user either manually reconnects it using Connection Manager or attempts to access the Internet using a Connection Manager aware application. In this case, the Connection Manager opens the packet connection for the user.
The packet data connection is suspended only in the case of a voice call, but it is not suspended if the user makes a circuit-switched RAS connection. In the latter case, the data session is terminated.
If the OEM wants to keep the connection absolutely always on by having a reconnect application that automatically reconnects the packet connection if the user disconnects it for some reason, then Microsoft recommends that the OEM set the priority of such a connection to be CONNMGR_PRIORITY_IDLEBKGND or lower so that it does not prevent applications such as background sync from connecting when the packet connection is idle.
|If an application attempts to transmit data while in the suspend state, the connection may be dropped.|