Skip to main content

Meeting Notes (Re: A proposal for changes to SipSession handling)

  • From: Binod < >
  • To:
  • Subject: Meeting Notes (Re: A proposal for changes to SipSession handling)
  • Date: Thu, 11 Jul 2013 12:59:56 +0530
  • List-id: <>

Since this was the only major item discussed yesterday, just recording my
notes here.

Attendees : Nitzan, Eric, Brian, Keith, Tom, Binod (Sorry, if I missed anyone).

- There were concerns around managing the lifecycle of the new interface (SipCall), specifically
for automatic invalidation. And the usecase for creating a SipCall from a SipApplicationSession
is not strong enough. So, we decided not to have a createSipCall method on SipApplicationSession.
  So, the SipCall cannot be obtained other than from a SipSession.

- There were doubts expressed in the EG meeting that the name SipCall may be misinterpreted
by some developers. So, we are looking for a new name. The current choices are ForkingContext
  or DerivedSessionContext. We will have a separate email to decide that.

- There is no strong usecase for getId() so far. Tom will look more closely at any possible usecase.
  If we don't have, the getId will not be included.

- We discussed the ability to save session/applicationsession as an attribute. We have the concurrency
chapter recommending users to submit a task with 236 executor service, for doing anything in the
scope of a SAS. That implicitely require that applications save IDs in the AttributeStore. But everyone
agreed that spec should clarify what can be stored in an AttributeStore. 289 spec only states
that message can be stored as an attribute. We may look at having helper classes in the spec to help
avoid applications writing boiler plate code to obtain session objects (eg: java.util.Objects in JDK).
  Tom is investigating, if the concurrency issue can be handled somehow.


On Tuesday 09 July 2013 06:40 PM, Strickland, Tom wrote:
Thanks for your  comments Binod. My reply is inline.

On 9 July 2013 12:38, Binod < <mailto: >> wrote:

    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

It is useful for logging.
It could also be used if we added a getSipCall(String) method to SipApplicationSession.

    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 directly.


    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 005110
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, 
distribution or
copying of this communication is strictly prohibited. If you have received 
communication in error, please notify us immediately by replying to the 
message and
deleting it from your computer. Thank you. Thrupoint, Inc.

A proposal for changes to SipSession handling

Strickland, Tom 07/05/2013

Re: A proposal for changes to SipSession handling

Binod 07/09/2013

Re: A proposal for changes to SipSession handling

Strickland, Tom 07/09/2013

Meeting Notes (Re: A proposal for changes to SipSession handling)

Binod 07/11/2013
Please Confirm