Below are some general and user-interaction example call flows illustrating R-IM-SSF behaviours.
|
In the following diagrams, messages related to different SIP dialogs display in different colours to help interpret the call flows. To keep it simple, 100 Trying provisional responses and PRACK/200 OK messages for reliable provisional responses are not shown (though the R-IM-SSF does send or handle those messages as appropriate).
|
General call flows
Below is the typical basic call flow for an IN-initiated call that is answered. The calling (A) party hangs up at call end.
|
|
The R-IM-SSF sends both 180 Ringing and 200 OK on call answer if the IN protocol in use does not support an explicit alerting event detection point (EDP), as many SIP applications expect such a message sequence.
|
Call alerting
The R-IM-SSF will arm the appropriate alerting event detection point (EDP) and handle the corresponding EventReportBCSM if the IN protocol in use supports it.
Forked SIP dialog - call setup
SIP dialog forking for parallel alerting is supported for IN protocols that provide call party handling operations. The call flow below illustrates call setup when the SIP dialog is forked.
Forked SIP dialog - call answered
Once a forked call leg answers, the leg is moved to the primary call segment (if necessary) and other legs are disconnected when the SIP-AS CANCELs the INVITEs.
Leg hold
Leg hold and resume is supported for IN protocols that provide call party handling operations. Below is the typical call flow for a leg hold procedure.
An attempt to place a leg on hold may fail or be rejected by the MSC for various reasons. In these cases, the R-IM-SSF will always respond to the re-INVITE with the same error response.
The R-IM-SSF will immediately reject an attempt to place a leg on hold when using an IN protocol that doesn’t provide call party handling operations.
User-interaction call flows
User interaction using direct mode
Below is the typical call flow for a pre-call announcement using direct mode. The call is allowed to proceed after the announcement completes.
User interaction using an assisting dialog
Below is the typical call flow for a pre-call announcement using assisting mode. The call is terminated after the announcement completes.
User interaction using a SIP MRF announcement device
Below is an example call flow for a pre-call announcement played using an MRF in the SIP network. The call is terminated after the announcement completes.
User interaction on call answer
Below is an example call flow for an announcement played to the B party as soon as they answer the call. The call leg is automatically placed on hold for this use case. This example shows the announcement played using an MRF in the SIP network, but the announcement could be played using any supported method.
Mid-call user interaction
Below is an example call flow for a mid-call announcement played to the B party. The target call leg must be placed on hold using a re-INVITE before beginning the announcement procedure if the announcement should only be played to the one call party. The call leg is returned from hold with another re-INVITE after the announcement completes. This example shows the announcement initiated using an ETC operation, but the announcement could be played using any supported method.
