|
New call leg
An incoming INVITE that is not creating a new network-initiated call and is not related to user interaction must identify the session it relates to in at least one of the following ways:
-
by including the oc-rimssf-session parameter in the top-most Route header. The return Route added by the R-IM-SSF in an INVITE sent to a SIP-AS already includes this parameter to identify the session; so a SIP-AS that simply forwards the INVITE doesn’t need to do anything more.
-
by including the oc-rimssf-session parameter in the Request-URI. The Contact header contained in the 200 OK response to an INVITE creating a new network-initiated call includes this parameter; so a SIP-AS that uses this Contact header as the Request-URI when adding further legs to the call doesn’t need to do anything more.
-
by using the session-id field of the Origin SDP parameter. The SDP included in the INVITE sent to a SIP-AS already contains this value; so a SIP-AS that uses the same SDP in the INVITE forwarded back to the R-IM-SSF doesn’t need to do anything more.
The R-IM-SSF attempts to determine the session ID by applying the rules above in the order given. The R-IM-SSF stops evaluating the rules once a session ID is found. If a session ID is not found, or a session ID is found that is not recognised, then the R-IM-SSF responds to the INVITE with a 503 Service Unavailable final response.
Assuming an active session is found, the incoming INVITE creates a new call leg in the corresponding IN call. If the new call leg represents the B party, the R-IM-SSF sends RequestReportBCSMEvent and Connect operation requests to arm the appropriate EDPs in the MSC, and route the call to the destination address. For any other call leg, the R-IM-SSF sends an InitiateCallAttempt operation request to create the new call leg, followed by RequestReportBCSMEvent and Continue operation requests to arm the appropriate EDPs and begin call leg routing.
|
The R-IM-SSF will populate the user variable user.rimssf.leg.invite in the interceptor script context with the incoming INVITE message, as described in Interceptors for Network Initiated Calls, whenever a Connect or InitiateCallAttempt message is sent to the network, regardless of whether the call was IN or SIP initiated.
|
The R-IM-SSF arms all EDPs in in the RequestReportBCSMEvent operation in Interrupted mode, except for the abandon EDP when using CAPv2, as this protocol only supports the Notify & Continue mode for this EDP. The R-IM-SSF determines which EDPs to arm based on information contained in the INVITE:
-
if the INVITE contains a Record-Route header, or the Contact header URI is not the local URI of the R-IM-SSF, then the R-IM-SSF arms all EDPs, and monitors the call leg for its entire duration
-
otherwise, the R-IM-SSF arms all EDPs except disconnect, and only monitors the call leg until it is answered or fails for some reason (busy, no answer, and so on).
After the Connect or Continue operation has been sent by the R-IM-SSF, it sends a 183 Session Progress provisional response for the INVITE to the SIP-AS.
|
Multi-leg call scenarios such as parallel alerting require an IN protocol that supports more than two parties in a single call. Currently the only relevant protocol supported by the R-IM-SSF is Ericsson INAP CS1+. If an initial INVITE is received to establish a new call leg but the maximum number of call legs supported by the IN protocol has already been reached, then the R-IM-SSF sends a 503 Service Unavailable final response to the INVITE.
|
User interaction
The R-IM-SSF identifies an INVITE for user interaction in a number of ways. The following table describes how the R-IM-SSF may identify such an INVITE and what configuration information is used to handle it:
| Identified by… |
Required Configuration |
A Request-URI containing the play parameter.
|
The value of the play parameter is the URL of the announcement to play. A URL announcement mapping must be configured in the R-IM-SSF for this URL.
|
|
A prefix announcement mapping must be configured in the R-IM-SSF for the prefix.
|
A content type of application/mediaservercontrol\+xml.
|
A media XML announcement mapping must be configured in the R-IM-SSF for the service key of the triggering InitialDP. If the call was a SIP network-initiated call, then a media XML announcement mapping must be configured for a service key of 0.
|
Additional service configuration information determines whether to play the announcement in direct or assisting mode. If in assisting mode, an EstablishTemporaryConnection operation request is sent by the R-IM-SSF to the MSC. A ResetTimer operation is also sent if the configured reset timer timeout period is greater than 0. The R-IM-SSF then waits for a response from the MSC.
Announcements using the IN
If the announcement is played in direct mode, or the MSC/SRF responds with an AssistRequestInstructions operation on an assisting dialog with a correlation ID matching that sent in the EstablishTemporaryConnection operation, then the announcement is played using the IN, and the R-IM-SSF sends a 200 OK response to the SIP-AS for the announcement INVITE. Once the R-IM-SSF receives the ACK for the 200 OK from the SIP-AS, the R-IM-SSF then sends ConnectToResource and PlayAnnouncement operation requests to start the announcement. A ResetTimer operation will also be sent if the configured reset timer timeout period is greater than 0.
Announcements using the SIP network
The MSC may play an announcement using a SIP MRF by sending an INVITE towards the R-IM-SSF. In order for the R-IM-SSF to recognise this INVITE and correlate it with the correct session, the INVITE must have a Request-URI with user equal to either the full assistingSSPIPRoutingAddress address digits or the correlation ID part only from the EstablishTemporaryConnection operation (if using combined mode), or a Request-URI with user equal to the correlationID digits from the EstablishTemporaryConnection operation (if using separate fields). A Service Composition Selection extension component is implemented by the R-IM-SSF to perform this session correlation. If a correlated session is found, the SCS extension routes the INVITE to the session (which may be on another cluster node).
Once the correct R-IM-SSF session receives the INVITE, the R-IM-SSF forwards the announcement INVITE received from the SIP-AS to the media server address configured in the announcement mapping, or the default media server address configured for the R-IM-SSF if the announcement mapping does not have a value set for this parameter. The response from the MRF is forwarded back to the SIP-AS. If the MRF responds to the INVITE with a 200 OK, a 183 Session Progress provisional response with the SDP from the MRF is sent to the MSC so that the media connection can be established. Further in-dialog requests such as INFO sent by the SIP-AS or MRF are automatically proxied by the R-IM-SSF to the corresponding peer.
Mid-call announcements
The R-IM-SSF supports user interaction mid-call, that is, any time after the initial trigger when the call is being routed to a second call party or a second call party has already answered the call. An INVITE for a mid-call announcement must identify the call leg that the announcement is to be played to by including a Target-Dialog header as defined in RFC 4538. The Target-Dialog header includes the Call-ID and local and remote tags (from the R-IM-SSF’s perspective) that identifies the relevant SIP dialog for the call leg in the R-IM-SSF.
The R-IM-SSF supports additional special-case behaviour for user interaction on call answer. In a two-party call, if the SIP-AS sends an INVITE for user interaction for the second call party immediately after receiving the 200 OK from the R-IM-SSF for call answer and before forwarding the 200 OK upstream back to the R-IM-SSF, then the R-IM-SSF will automatically split the second call leg into a separate call segment before playing the announcement, and will move the leg back to the primary call segment again when the announcement completes. In any other case, if mid-call user interaction requires the target call leg to be split to a separate call segment first then re-INVITEs for media change indicating hold and resume for that call leg must be sent before and after the user interaction sequence.
|
|
Mid-call user interaction requires an IN protocol that supports this function. Currently the only relevant protocol supported by the R-IM-SSF is Ericsson INAP CS1+. The R-IM-SSF will include the tdialog option tag in the Supported header of the INVITE towards the SIP-AS, and a 200 OK response to an INVITE sent by the SIP-AS, if mid-call user interaction is supported by the R-IM-SSF instance. If an INVITE is received requesting mid-call user interaction but the IN protocol in use does not support this function, the R-IM-SSF sends a 488 Not Acceptable Here final response to the INVITE.
|
|
|
The R-IM-SSF recognises the following updates via an INVITE received in the context of an existing dialog:
The R-IM-SSF supports leg hold and resume through a media change in a new SDP offer. If the new SDP contains a session attribute with value sendonly and the corresponding IN call leg is not currently being held, then a HoldCallPartyConnection operation request is sent by the R-IM-SSF. If the new SDP contains a session attribute with value sendrecv and the corresponding IN call leg is currently held, then a Reconnect operation request is sent by the R-IM-SSF. If sendonly is received for a leg that is already held, or sendrecv is received for a leg that is not held, the R-IM-SSF performs no action on the IN dialog and simply responds to the INVITE with a 200 OK.
|
|
Leg hold and resume requires an IN protocol that supports these functions. Currently the only relevant protocol supported by the R-IM-SSF is Ericsson INAP CS1+. If an INVITE is received requesting leg hold but the IN protocol in use does not support this function, the R-IM-SSF sends a 488 Not Acceptable Here final response to the INVITE.
|
|
|
A CANCEL or BYE terminates a SIP dialog. The R-IM-SSF handles such an event as follows:
Normal call leg termination
The R-IM-SSF determines whether to disconnect just the corresponding IN call leg or the entire IN call based on the following conditions:
-
if call monitoring is only until call answer (rather than call termination) and the call has already been answered, then only the call leg is released;
-
if the call is an IN initiated call and the outgoing SIP dialog, representing the incoming (calling party) call leg, has terminated, then the call is released;
-
if no outgoing call legs would remain after the IN leg was disconnected, then the call is released;
-
if the call is a SIP network initiated call and only one call leg would remain after the IN leg was disconnected, then the call is released;
-
otherwise, only the call leg is released.
The call is released using the ReleaseCall operation request. A single leg is released using the ReleaseCallPartyConnection operation request.
User interaction
If a dialog representing user interaction is terminated by the SIP-AS:
-
if the announcement is being played using the IN, then a Cancel operation request is sent by the R-IM-SSF to cancel the PlayAnnouncement request previously sent to start the user interaction; else
-
if the announcement is being played using the SIP network, then a CANCEL or BYE request (depending on current state) is sent to the MRF to terminate the announcement.
Once the announcement is confirmed terminated, the R-IM-SSF then sends a DisconnectForwardConnection operation request to the MSC to end the user interaction.
|
