SIP forking is feature that lets a downstream proxy "fork" a request, meaning it forwards a request to several contacts in parallel
The proxy will forward all 1xx and 2xx responses back to the caller (UAC), so it is possible for the caller to receive multiple 1xx or 2xx responses for the initial request. Each response with a different To-tag represents a new dialog.
The JAIN SIP 1.2 RA Type API specifies some events to handle forking cases, so that the multiple dialogs resulting from a forked request can be managed and cleaned up easily.
The SIP RA’s forking support follows this basic model, and only applies if the application is using dialog activities.
The original dialog activity is created when the initial dialog-creating request is sent, and the application creates a new outgoing dialog using
Each 1xx response that arrives, containing a To-tag that has not been seen before in this transaction, will create a new early dialog. The exception is the first 1xx response with a To-tag; this is taken to be part of the original dialog.
When a 2xx response arrives, the dialog that it matches is retained and goes to the Confirmed state. All other early dialogs are ended.
When any other final response arrives (3xx-6xx), all early dialog activities are ended.
When sending an initial dialog-creating request, the UAC SBB should
attach to the original dialog activity. If a forked response arrives
that creates a new dialog, the SIP RA will fire an event on the original
dialog activity, so that the SBB can know that there is a new dialog
activity. The event object is a
The SBB can get a reference to the new dialog activity by calling
The SBB can attach to the new activity and send requests on it.
If a 2xx response arrives on any early dialog, the RA will fire the
normal response event. If a 2xx response arrives with a different To-tag
to any early dialog, the RA will fire another
All other early dialogs will be ended.
Any late 2xx responses with different To-tags will be dropped. In this case the SIP RA will send an ACK then a BYE to tear down this forked dialog at the server. Late 2xx responses are not passed up to the SBB.
UAS applications typically do not fork; however if the application is a back-to-back user agent (B2BUA), then it may need to create multiple server dialogs to correspond to the client dialogs created in the UAC procedures above. This is essential if the application needs to receive mid-dialog requests while the dialogs are in the Early state.
The JAIN SIP resource adaptor type defines the method
This method should be called when the UAS forwards a dialog-creating
response with a different To-tag to the original dialog. This method
will forward the response upstream, and return a new dialog activity.
The application can attach to the forked dialog activity in order to
receive any mid-dialog requests on the dialog.
The dialog activity contains a reference to the original server
transaction. When a final response is sent on the transaction, or by
passing a 2xx response to
all other early dialog activities will end automatically.
The B2BUA example application handles forking events and the multiple client and server dialogs that may be created.