What is downstream forking?
Downstream forking occurs when something downstream (e.g. S-CSCF) of the application (Sentinel) decides to fork a call (e.g a result of subscriber registration data). A downstream call branch to each destination will be created. All 1XX(with the exception of 100) and 2XX responses must be forwarded upstream and the first final response forwarded will result in all remaining forks with active transactions being terminated using the CANCEL method.
It is possible for one or more additional 200 OKs to arrive whilst the CANCEL is still being processed, in this event these will also be forwarded upstream. In the event this happens, 3GPP TS 24.229 states the UE should ACK the additional 200 OKs and follow immediately with a BYE.
Call flows
S-CSCF Downstream Forking call flow examples. For simplicity, these examples have non-reliable provisional responses.
Downstream fork error
SCSCF forks INVITE downstream of Sentinel. B-Party- B' send 487 Final response
Feature description
Feature script name |
SipDownstreamForking |
|---|---|
Applicable contexts |
SIP service |
Prerequisite Features |
None |
The SipDownstreamForking feature handles a SIP call forked downstream by the S-CSCF, an application, or other UAS. This feature must be triggered on every early response and request until the call has been setup.
For each new downstream forked leg (dialog) response, the feature will import the leg into the Sentinel SIP Service and if the original INVITE was received upstream, the feature will forward the response on a new upstream leg (dialog) which is created by the feature and linked with the downstream leg. Subsequent early dialog messages on these legs will be be ignored by this feature but handled in the default way by the Sentinel SIP Service until a final response is received.
When the feature receives a final response, it will detach all other downstream legs and their linked upstream legs from the Service, delegating responsibility to the SIP SIS RA to clean up these remaining dialogs. In the crossover case where a CANCEL is received from the Calling Party and a Called Party forked leg answers, the forked leg that answered will be released (resulting in a BYE request sent).
|
Regardless of which leg sends the final error response, the SIP SIS RA will always send it the initial calling party leg. |
-
The imported downstream fork legs will have the following leg name format:
downstreamfork[unique session id]. -
The created upstream fork legs will have the following leg name format:
upstreamfork[unique session id].
The feature should be installed in the SipAccess_PartyRequest and as the first feature in the SipAccess_PartyResponse. It cannot be run in any other execution points.
Feature interaction
First response on a new forked dialog
The first response on a new forked dialog is delivered by the SIP SIS RA on the activity which sent the INVITE request. Subsequent responses are delivered on the leg created by this feature activity.
If another feature is also using this first response it will be necessary to determine the correct leg as follows:
Leg actualResponseLeg = legManager.getLeg(response.getSipSession());
The leg will only differ from the leg associated with the INVITE dialog if the response.isForked() returns true.
Error scenarios
| Scenario | Handling |
|---|---|
Error occurred when creating upstream forked Leg |
Increment ImportUpstreamForkedLegError |
Error occurred when importing downstream forked Leg |
Increment ImportDownstreamForkedLegError |
