Queuing Multiple Calls

When a higher-layer protocol makes multiple calls on the same activity, they are queued in the activity's List of Active Calls. Only one call can be in STATE_SEND_FRAGMENTS at any given time. The call that is in this state is the Activity's Current Call.

If calls on the activity are not being overlapped (call's Overlapping element is set to FALSE) as described in section, the client MUST receive the server's response before the next call in the queue can be processed (meaning transition to STATE_SEND_FRAGMENTS). This behavior is in accordance with [C706]. The presence of a next queued call affects the next state of the Current Call after it has received the server's response: if there is no next queued call, the Current Call will transition to STATE_ACK_PENDING. The transition to STATE_ACK_PENDING triggers the initialization of the Delayed-Ack Tmer. If there is a next queued call, the Current Call transitions immediately to STATE_COMPLETE and Current Call is set to the next queued call.

If overlapping calls are being made on the activity (call's Overlapping element is set to FALSE and call's activity's Client Address Space Supports PF2_Unrelated Flag is set to true), the client does not have to wait for the client to reach STATE_COMPLETE or STATE_FAULT before beginning the next call. When overlapping calls are being made, the client will set the Activity's Current Call to the next call in the List of Active Calls (if there is a next call) whenever the Current Call transitions to STATE_DISPATCHED.

In all cases, calls MUST still be sent in order of their call_id and all fragments of one call MUST be sent (Call transitions to STATE_DISPATCHED) before fragments of another call can be sent.