Thanks for your comments Binod. My reply is inline.
On 9 July 2013 12:38, Binod < <mailto: >> wrote:
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
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
-- *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,
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.
Meeting Notes (Re: A proposal for changes to SipSession handling)