Skip to main content

Re: EDR draft updated - dialog termination section

  • From: Eric Cheung < >
  • To:
  • 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 7.2.5.1 describes UA behavior in terminating dialogs/usages. But it should really specify container behavior.

I propose to modify the section as follows:

7.2.5.1

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)


7.2.5.1.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 table are:
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.


Thanks
Eric


EDR draft updated.

binod pg 04/16/2013

Re: EDR draft updated.

Jonas Borjesson 04/16/2013

Jonas comments [Re: EDR draft updated.]

binod pg 04/17/2013

Re: EDR draft updated - dialog termination section

Eric Cheung 04/17/2013

Re: EDR draft updated - dialog termination section

Jonas Borjesson 04/17/2013

Re: EDR draft updated - dialog termination section

Nitzan Nissim 04/21/2013

Re: EDR draft updated - dialog termination section

Eric Cheung 04/22/2013

Re: EDR draft updated - dialog termination section

binod pg 04/22/2013

Re: EDR draft updated - dialog termination section

Eric Cheung 04/22/2013

Re: EDR draft updated.

Eric Cheung 04/17/2013

Eric's comments [Re: EDR draft updated.]

binod pg 04/17/2013

Re: EDR draft updated.

Strickland, Tom 04/17/2013

Re: EDR draft updated.

binod pg 04/18/2013
 
 
Close
loading
Please Confirm
Close