New call leg
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
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
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
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
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 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).
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
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:
Request-URI containing the
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
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
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
PlayAnnouncement operation requests to start the announcement. A
ResetTimer operation will also be sent if the configured reset timer timeout period is greater than
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.
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
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
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
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.
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
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.