Re: EDR draft updated - dialog termination section
- From: Eric Cheung <
- Subject: Re: EDR draft updated - dialog termination section
- Date: Wed, 17 Apr 2013 16:52:24 -0400 (EDT)
- List-id: <jsr359-experts.sipservlet-spec.java.net>
As discussed at today's call, section 184.108.40.206 describes UA behavior in
terminating dialogs/usages. But it should really specify container
I propose to modify the section as follows:
Remove first sentence.
Add following sentence to the end:
The following sections provide examples of correct SIP servlet
container behavior in terminating SIP dialogs based on these RFCs.
In these examples, the terms UA, UAC and UAS should be understood
to mean the SIP servlet container acting on behalf of an UA
application that has called SipSession.terminateDialog().
(Note to EG, not to be included in EDR:
the advantage of writing it this way is that the wording in the
following sections are very close to the RFCs)
220.127.116.11.2 SUBSCRIBE dialog
Replace third bullet with (borrowing wordings from Jonas, and
trying to stay close to RFC3265):
- A subscription is destroyed when a UA acting as notifier sends a
NOTIFY request with a "Subscription-State" of "terminated". If there
are no other dialog usage, the SIP dialog is terminated.
- A UA acting as a subscriber cannot explicitly terminate a
subscription. A UA acting as subscriber may send a SUBSCRIBE request
with an "Expires" header of 0 in order to trigger the notifier to send
a NOTIFY request that destroys the subscription as above.
(I am not sure if we decided on container behavior if it does not
receive such a NOTIFY from the notifier) I think the options on the
1) do nothing, let the app handle
2) time out and consider the dialog terminated
3) invoke SipErrorListener interface (needs new method)
Responses to some of the other comments:
Jonas and Tom both commented on the interface name
AutomaticProcessingListener. It was deliberately general to
accommodate other functionalities where the container performs
automatic processing on behalf of the application, e.g. if we decide
to add automatic handling of SIP session-timer.
Re Jonas' suggestion to change the names of
AutomaticProcessingListener methods to onXXX(). I personally also
prefer the onXXX() naming convention, but the methods in the other
listeners are not named this way e.g.
SipSessionListener.sessionCreated(). So I try to be consistent with
that naming convention.
Jonas' comment on restrictions on modifying message in place: There
are certainly modifications that will mess things up e.g. if the
container is sending an error response to terminate an INVITE early
dialog, but the app changes it to 200 OK, or container is sending
SUBSCRIBE with Expires 0 and the app changes it to something else.
However, there may be a lot of these cases so may be hard to enumerate
them all. Perhaps we can just say app should not subvert the RFCs and
container behavior in terminating the dialog. Otherwise the behavior
may become unpredictable.