Skip to main content

Re: SIP Dialog termination proposal

  • From: Binod < >
  • To:
  • Subject: Re: SIP Dialog termination proposal
  • Date: Thu, 28 Feb 2013 14:04:19 +0530
  • List-id: <>

Here is the summary of our discussion yesterday
on the meeting.

The automatic termination of dialogues would require  the SAS
expiry to be postponed until the dialog termination is over. That means
if the AutomaticProcessingListener is invoked, the sessions in the
SIP message will be invalid? And the attributes may not exist?

If we do not allow an application to declaratively specify the
listener, then this issue can be mitigated to some extend, since
the listener wont be invoked for automatic termination. But that
might be limiting the application developer.

So, here are some choices, we are left with. Please comment.

1. Let the explicit invalidation be the only way to terminate the dialog.
    Application will need to call terminateDialog on SAS expiry listener.
    AutomaticProcessingListener may be configured declaratively.

2. Container will invoke automatic termination on SAS expiry, probably
as per a specific boolean setting. But the listener will not be invoked at all.

3. Define a new mode , where on SAS expiry, the terminateDialog will
be invoked automatically depending on SAS expiry timer. But in this case,
we specify that, when the SAS expiry timer is invoked, it will not expire the
session, instead will terminate the dialog. And the SAS will follow the
    invalidateWhenReady mechanism for expiry.

Otherwise, as we discussed in the meeting, the listener need to use SipServletRequest
or SipServletResponse as parameter to methods instead of the SipServletMessage.


On Wednesday 27 February 2013 10:04 PM, Eric Cheung wrote:
Hi Nitzan

1) I like your idea of automatic dialog termination that is triggered by invalidating the SipSession, either explicitly by SipSession.invalidate() or indirectly by SipApplicationSession.invalidate().

However, if the application needs to modify outgoing messages or be notified of incoming messages to perform some function, the SipSession is probably needed. There may also be cases where application wants to keep the SipSession around. So I think the explicit terminateDialog is still needed.

2) The rationale for passing in AutomaticProcessingListener is so that different SipSessions may have different listeners, and also the listener can be changed programmatically.


On 2/27/13 5:58 AM, Nitzan Nissim wrote:
Hi Eric

I have a couple of suggestions regarding the proposed API:

1. Wouldn't it make sense to define a mode of  "automatic dialog
termination" that could be set on/off (same as invalidateWhenReady), and
then initiate dialog termination when the application calls for invalidate
() explicitly or when SAS is expiring?
Do you see a common use case where an app would like to call to
terminateDialog and leave the session not invalidated? In the default case
invalidateWhenReady will also cause the invalidation of the session, so
this will have the same affect.
I think that the advantage of the alternative approach is:
       No new API is needed
The application code can keep looking as though it is not aware of a
       difference between the session and the dialog state (only
       configuration enables/disables dialog termination on session
invalidation), which better serves the principle of application code
concentrating on business logic and less on SIP protocol internals
SAS expiration will cause invalidation and dialog termination without
       any additional method call

2. Shouldn't it be possible to define the AutomaticProcessingListener in
the app descriptor/annotation, so if defined, will be invoked during dialog
termination, without having to pass it as a parameter?


Nitzan Nissim
SIP Container Architect, WebSphere SIP Infrastructure
IBM Software Group, AIM
Israel Software Lab
+972 (54) 6976107
+972 (8) 9482326

From:    Eric 
Cheung< >
Date:    20/02/2013 06:37 PM
Subject:    SIP Dialog termination proposal

Attached is the updated proposal based on discussion at the F2F.
[attachment "JSR359_DialogTerm_v0_2.pdf" deleted by Nitzan

Re: SIP Dialog termination proposal

Binod 02/22/2013

Re: SIP Dialog termination proposal

Eric Cheung 02/22/2013

Re: SIP Dialog termination proposal

Binod 02/25/2013

Re: SIP Dialog termination proposal

Eric Cheung 02/26/2013

<Possible follow-up(s)>

Re: SIP Dialog termination proposal

Nitzan Nissim 02/27/2013

Re: SIP Dialog termination proposal

Eric Cheung 02/27/2013

Re: SIP Dialog termination proposal

Binod 02/28/2013
Please Confirm