 |
Sip RA Type enhancement discussion
Abstract
The information on this page is intended as background for a discussion of the Sip RA Type as defined (recommended) in the JSLEE specification.
The goal of the discussion is to come up with a proposal for an enhanced sip RA Type definition, optimally backed up not only by the Mobicents team to enable portability of applications.
This page is to be considered a living document to be updated as a result of a discussion in the forum after consensus has been reached on specific subjects.
Background
The JSLEE specification (both version 1.0 and 1.1) defines the activities ServerTransaction and ClientTransaction only.
This is a good base but it makes writing many classes of applications unnecessarily difficult.
To see this lets look at the 3pcc example application in Mobicents examples.
This is a standard 3pcc application where the call controlller sets up two dialogs, one with each party in the call. The sip signalling is done only between the call controller and the parties (not directly between the parties).
UA A ------------ 3pcc ------------ UA B
Dialog A Dialog B
During the setup of the two dialogs the Sbb responsible for the sip signalling is attached to two ACIs representing the corresponding client transaction.
In this way the two client transactions can be associated with one single Sbb which is what is needed to perform the work.
At some point in time the 3pcc session will be terminated by terminating dialog A and B.
Say that this is done by UA A hanging up and a BYE is sent to the application. Since the original activities are client transactions they have already ended and the Sbb may have been removed by the SLEE already. Even if it has not been removed there is no way of associating the server transaction based ACI resulting from the BYE with the client transaction based ACI starting dialog A (without using mechanisms such as named ACIs e.t.c.)
(In the current 3pcc example application the dialog association and state information is stored outside the ACIs discussed here)
This situation calls for an enhanced sip RA Type.
Other vendors have already implemented a dialog based activity to solve this type of problem.
Sip RA Type with Dialog activity
Introduction
Introducing a dialog activity is a natural strategy to solve the problem sketched above.
This section describes how the 3pcc application benefits from a dialog activity and points out a number of questions concerning the implementation of a dialog activity.
Description - 3pcc with dialog activity
It's very easy to see how the dialog activity will solve the problem, let's go through this in a few lines describing one possible way of doing it.
- The Sbb sends an INVITE to UA A and at the same time it creates a dialog, a corresponding dialog based ACI and attaches itself to it.
- The Sbb will receive responses to the INVITE on the dialog based ACI (called ACI A).
- When UA A responds OK dialog B is established and the same procedure with dialog and ACI creation is followed.
- The 3pcc session with two confirmed dialogs is established and the dialog activities keep being alive during the call.
- A simplistic but fully viable approach for associating the two dialogs is to have the Sbb attached to both of them. Another strategy is to use child Sbbs that each is attached to exactly one dialog based ACI. In the first case it is convenient to use a custon acitivity context interface.
- A BYE request is sent from UA A to the application and it gets delivered to the Sbb on the dialog A ACI.
A sip RA type supporting this can contain the activities ClientTransaction, ServerTransaction and Dialog.
Note that the Sbb still has immediate access to the ClientTransaction in its onXXXResponse methods via the ResponseEvent.getClientTransaction method.
Issues
There are a few issues that must be set to define the behaviour of a sip RA Type with a dialog activity.
Server transaction or dialog
In the 3pcc example the application represents the UAC side and will actively choose what type of ACI to create and attach to (ClientTransaction or Dialog).
In the opposite case where e.g. an INVITE is delivered to an Sbb the situation is more complicated.
Either the ACI can be based on a ServerTransaction or Dialog.
Since dialog support brings some overhead and not all applications need it, it can be questioned if it's a good idea to deliver an initial INVITE on a dialog activity per default.
Let's see what can be done if the application is made responsible for deciding if a dialog activity will be used:
- On an initial INVITE the application decides that it will act on messages in the dialog.
- The (root) Sbb receiving the INVITE may detach from the server transaction based ACI.
- The dialog is obtained with SipProvider.getNewDialog(Transaction) and the dialog based ACI is created with SipActivityContextInterfaceFactory
- The relevant Sbb(s) is attached to the new dialog based ACI
- A response is sent using the server transaction
- Next incoming request (e.g. a BYE or a re-INVITE) is delivered on the dialog ACI.
Since the dialog must be created before any response is sent it is reasonable to assume that the change from server transaction based ACI to dialog can be done as easily as described here.
After this different things can happen:
Cancel
Since a CANCEL is not an in dialog message it can be argued that is should be delivered on a ServerTransaction activity but in theory it should be possible to deliver it on a Dialog activity (comment?).
Using a ServerTransaction activity requires us to have an initial event selector method that selects the same Sbb as the original INVITE was delivered to.
Delivering a CANCEL request on a dialog activity would make application writing easier because the root Sbb can attach any child to the activity and rely on the child receiving the CANCEL.
Also it is consistent with the approach that once the application has decided to use a dialog ACI subsequent requests are delivered on this ACI.
Timeout
If the dialog is not terminated gracefully (BYE request) there must be a mechanism for timing out the dialog, otherwise that activities could last forever. The SipListener.processDialogTerminated method should ideally be used to implement this in the RA. (What's the timeout mechanism for this method in the Nist stack?)
Forking
When an Sbb sends an initial INVITE multiple dialogs can result from this. The following piece from the javadocs for SipProvider.gerNewDialog :
"For UAC's Forked calls are handled as follows: The response of a forked call that completes the initially created dialog will use the original dialog that is associated with the transaction. Subsequent responses that correspond to other branches of the fork ( ie. with the same From header tag, and Call ID but different To header tags) result in the creation of additional dialogs that are associated with these responses. The created dialog is made available to the UAC ( Listener ) via the method ResponseEvent.getDialog"
says that there must be some precaution taken regarding responses from forked calls.
It will not be possible to call SipProvider.getNewDialog for the second response (fork), because this dialog has already been created.
For the fork there is a choice between:
- Deliver the response on the same client transaction and let the application obtain the dialog with ResponseEvent.getDialog.
- Deliver the respone on the dialog ACI corresponding to the fork.
Alternative 1 has the advantage that if the application does not wish to continue the fork dialog no corresponding ACI will be created.
+++---Transaction ACI coexisting with Dialog ACI
When the dialog ACI is created the server transaction ACI still exists.
What restrictions should be enforced the on application code to make programming easy and comprehensible?
For example, if the application creates a dialog ACI in the event handler method that receives a request, should it be illegal to stay attached to the server transaction ACI?
+++---Special dialog events
The OC sip RA includes special dialog state event such as SetupEarly SetupConfirmed.
What is the role of these events?
Is a SetupEarly event delivered apart from a 100 provisional event or is it a replacement for the provisional events?
Use cases
Conference application (generally interpreted here as an application associating multiple dialogs in a single logical session).
A simple conference can be implemented with a single Sbb attached to one dialog ACI per conference participant.
The state associated to a participant (e.g. time of joining the conference, maximal time of staying in the conference) can be stored as custom ACI attributes.
This design requires one Sbb to handle events belonging to all the attached dialogs. To access the dialog ACI and their state during an event handler method the Sbb must use the SbbContext.getActivities method. The entity (ACI) representing the participant can only have simple getters and setters and this design does not facilitate object oriented design.
Another design is to let use an Sbb representing the conference session (ConferenceSbb) and use one child Sbb to represent each conference participant. This design has several advantages.
First of all the local interface of the child Sbb, hereafter called PartySbb, can be equipped with any methods representing behaviour such as 'terminate' or 'reinvite'.
In the case of multiple dialogs resulting from a forked INVITE the dialogs will be associated to the corresponding PartySbb, this helps a lot to keep track of dialogs belonging to one forked INVITE.
The PartySbb can in turn use other Sbbs and possible store them in cmp fields. This is not possible in the first design because ACI attributes can not be of the type SbbLocalInterface (or derived types).
The ConferenceSbb obtains the child PartySbbs with the ChildRelation.iterator method.
The communication between ConferenceSbb and PartySbbs can be done synchronously and asynchronously. Asynchronous communication via a NullActivityContextInterface may be convenient for application specific events that may be emitted by either ConferenceSbb or PartySbbs.
Summary
Extending the sip RA Type with a dialog activity will make common tasks significantly easier. Once the issues are set it is easy to motivate a dialog based activity for the applications dicussed.
Sip RA Type with DialogAssociation activity
Introduction
This concept was discussed in a forum thread (http://forums.java.net/jive/thread.jspa?threadID=1155&start=0&tstart=0) and the purpose of it was to make application writing easier by letting the sip RA associate multiple dialogs in a single activity. The conference application is a good example.
The basic idea is that Sbbs are able to add dialogs to a single activity and also that the RA can add a dialog to an existing acitity by some criteria.
Description - Conference application with multiple dialog RA
This is a high level example to describe the idea.
Suppose that the conference application is to setup a conference session by inviting a set of participants. In this process it will ask the sip RA to create a DialogAssociation ACI with the underlying activity of type DialogAssociation.
One possible design is to let the SipActivityContextInterfaceFactory contain the methods
createDialogAssocationActivityContextInterface() : ActivityContextInterface
associateDialog(ActivityContextInterface, Dialog) (Not a clearcut factory method)
Also we want participants to be able to call in to the conference and let the sip RA associate incoming INVITEs with a To header containing 'confid_1234' and From header containing the URI of a conference participant (known in advance) to this activity so we set some kind of filtering property on the activity.
When a participant joins the conference by calling in to it the Sbb will get an INVITE delivered on the DialogAssociation ACI with an activity having the already associated dialogs on it.
This situation is kind of the convolution of the second design sketched above where there is one Sbb entity per participant.
Assessment
Pros:
It is very easy to let e.g. a child Sbb to be associated to all dialogs by attaching the child to the DialogAsssociation ACI.
The sip RA can associate dialogs to the ACI of a conference Sbb in different ways which is more powerful than using an initial event selector method. (This will in fact not work in the example above unless the root Sbb was instantiated as a result of an initial event selector method setting the custom name to 'confid_1234', if this is used as convergence name.)
Cons
The activity sketched here simply associates dialogs, it does not attach further state on each individual dialog. This makes it inconvenient to map state to each dialog. Such a mapping must be done externally by using some key for the dialog (remote party or dialog id) mapped to the state.
The JSLEE mechanisms extended with a dialog activity already contain good mechanisms for achieving the same goal as this activity gives us with the exception of the additional ways of associating different dialogs to the same ACI. (I.e. we are not restricted to the convergence name as a mechanism to route INVITEs to the corresponding Sbb)
Conclusion
Unless concrete use cases show that a DialogAssociation activity will reduce the complexity of an important set of applications it is not considered enough attractive. Not because it would be difficult to design or implement (not investigated here) but because it seems as if the Dialog ACI with an Sbb per dialog will offer a design more suitable for non trivial applications.
Proxying
Introduction
Proxying a request is a common task in sip applications and it is also a well defined mechanism. With the dialog ACI it is possible to write a B2BUA that does call stateful proxying, but it does represent a significant amount of work.
This task could be done very easily and highly performant with a proxy utility in the sip RA instead.
Description - B2BUA with proxy activity
This is a sketch of one possible way of designing a proxy mechanism by introducing a special activity for it.
The steps to proxy e.g. an INVITE are: create a proxy ACI with a configuration object handed to the SipActivityContextInterfaceFactory, e.g. SipActivityContextInterfaceFactory.createProxyACI(ProxyConfig config, Request request). Attach to the proxy ACI and request the proxy operation to start.
The result of the proxy operation is that the request is proxied in some mode according to the configuration and that the event handler methods of the attached Sbb get invoked if the configuration mandates this.
The whole idea is realized in the sip servlet specification and here some of the configuration options from this spec are listed:
- record route If true the proxy is call stateful, e.g. stays on the signalling path for the dialog.
- stateful If true the proxy is transaction stateful and can be used to fork requests to multiple destinations.
- supervised If true the event handler methods of attached Sbbs are invoked. Example a billing application wishes to measure the time between INVITE and BYE so it set the supervised parameter to true.
Issues
How should the proxy operation be requested to start?
There is no obvious equivalent to this type of request in the current sip RA.
Alternatives:
- Custom method on the JainSipResourceAdaptorSbbInterface e.g. proxyTo(List sipURIs, ActivityContextInterface)
- Method on the activity itself. ProxyActivity.proxyTo(List sipURIs)
More?
It would be instructive to have a number of examples of where the proxy operation will come in handy (except for a pure proxy application). This is just to validate the asssertion that proxying will be needed frequently enough to motivate a sip RA extension.
-- Main.niklasuhrberg - 21 Mar 2006
|