Re: A proposal for changes to SipSession handling
- From: "Strickland, Tom" <
- Subject: Re: A proposal for changes to SipSession handling
- Date: Tue, 9 Jul 2013 14:10:30 +0100
- List-id: <jsr359-experts.sipservlet-spec.java.net>
Thanks for your comments Binod. My reply is inline.
On 9 July 2013 12:38, Binod
> Hi Tom,
> In general, I like the idea. I also like the AttributeStore. Here are some
> questions and comments.
> 1. Again, we may have a naming dilemma. Shouldnt we call this interface
> ForkingContext or DerivedSessionContext?
> The name SipCall can be easily misinterpreted.
I am open to new ideas for the name.
2. Could you please tell me the use of getId() ? Is that strictly needed?
It is useful for logging.
It could also be used if we added a getSipCall(String) method to
3. Do we really need explicit creation of SipCall? Is there a use case for
> that? Why should we allow 0-n sipsessions per
> sipcall? Shouldnt it be 1-n sipsessions per sipcall?
Two use cases:
UC-1. An Alice-Bob B2BUA, where Alice has sent a out-of-dialog SUBSCRIBE,
propagated to Bob in a new separate SIP dialog. Downstream forking occurs,
resulting in a single final response and multiple NOTIFYs in different Bob
branches. Assume that we want to propagate this forking back to Alice.
(This is, admittedly, an unusual scenario, but it does allow us to create a
transparent B2BUA that looks as much like a proxy as possible). For each
forked NOTIFY coming back from Bob, you will need to create a similar
NOTIFY back to Alice. In this scenario, you may want to explicitly create
the derived SipSession and then use that to create the NOTIFY back to
Alice. Note that, in this situation, we are talking about a situation in
which each SipCall has 1-n SipSessions, but this is a use case for creating
a SipSession without doing so as a side effect of creating a SIP message.
UC-2. I have, as part of a past project, written a high-level telephony
API, that took the following steps:
UC-2.1 Create an "endpoint" for Bob. This is just a bag of information for
an outbound call to Bob - a String label for the individual, a SIP URI,
other miscellaneous details, such as timeout.
UC-2.2 Put that endpoint in a call. This may be achieved using an INVITE
or a REFER.
The problem is that you cannot store the information relevant to Bob's
endpoint anywhere useful except a SipApplicationSession. The downsides of
this should be obvious, but I will come back to them in a moment. The
problem is that you cannot create a SipSession until you know what SIP
message you intend to send, and you do not know that in this use case until
you add the endpoint to the call. Storing this information in the
SipApplicationSession would be less convenient: if you no longer to store
the data, but the SipApplicationSession is still needed, you need to
manually remove each attribute. If you are storing attributes relevant to a
SipCall in the SipApplicationSession, then you also need to take steps to
avoid naming collisions between such attributes.
4. I think developers should be able to create SIP Servlet applications
> without storing SipSession and SAS in the AttributeStore.
> It should be containers responsibility manage objects such as
> SipSession and make sure that it is available as needed to the
> SIP Servlets.
If by this, you mean that an app developer should be able to get a
SipSession by ID, then I agree. However, I suggest that it is possible for
us to specify that they can alternatively store a SipSession, SipCall, or
SipApplicationSession and use it directly - we can do this by using a
project object that lazily fetches-and-caches the actual SipSession
container implementation internally and delegates to that for all
operations. getId() would always work. This saves a fair amount of
boilerplate code in a large proportion of SipServlet apps: every time that
I want to retrieve a SipSession, I have to have access to its
SipApplicationSession to do so, so I might have to get that by ID, and then
I go to the SipApplicationSession and get the SipSession by ID - and that
might be null... This is repetitive pointless code that could be eliminated
if the API was more helpful and offered the means to store a SipSession
> On Friday 05 July 2013 06:57 PM, Strickland, Tom wrote:
> Attached is our proposal for changes to SipSession handling in JSR 359.
> *Tom Strickland*, Software Developer, Thrupoint Software. Tel: +44 (0)
> 2920 005110
*Tom Strickland*, Software Developer, Thrupoint Software. Tel: +44 (0) 2920
Note: The information contained in this message may be privileged and
and protected from disclosure. If the reader of this message is not the
recipient, or an employee or agent responsible for delivering this message to
intended recipient, you are hereby notified that any dissemination,
copying of this communication is strictly prohibited. If you have received
communication in error, please notify us immediately by replying to the
deleting it from your computer. Thank you. Thrupoint, Inc.