Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog
RFC 6228

Note: This ballot was opened for revision 06 and is now closed.

(Cullen Jennings) Discuss

Discuss (2010-02-04 for -)
The draft needs to be explicitly clear about what conditions it helps in. The current text is not clear enough given that many people end up debating it and or confused. I think this is just a matter of getting more explicitly about these points and deleting any ones where it is not clear exactly what cases it  helps in. We just need to get these to the point where it is clear that they are factually correct. 

1.  Codec release - when resources for a specific codec has been
  reserved only for the stream that is terminated.  In that case the
  resources associated with that codec can be released.

I don't understand what resource is released. On some very old large gateways that loaded codecs into the DSP du to DSP memory limitations, I understand what codec released means but that does not make sense in this context. Please explain in email what gets released and in what real world scenarios this occurs then we can sort out what the draft needs to say. I obviously consider mobile batter operated devices over wireless to be very important use cases. 

  2.  Pre-conditions - when the dialog is terminated, procedures and
  resources associated to the pre-conditions for that dialog can be

Please clarify this to around the allocated bandwidth. I would also like to understand in what real world scenarios this is going to result in additional dialogs being set up once the bandwidth becomes available. You need to walk me through a scenario of how this is going to work. 

  3.  In-band security negotiation - when the dialog is terminated,
  procedures and resources associated with the in-band security
  negotiation for that dialog can be released.

Ditto on this. 

You wrote "[Christer] Whatever procedures takes place on the media plane in order to establish the security associated, and resources reserved in order to deal (encrypt/decrypt) with the secure media itself." I still don't understand what resources. Jari said that if a slow UA was still trying to set up a security associations by the time the 199 arrived, this could allow it to stop that and it might take a long time due to CPU speed and doing PKi computations. If this is what you mean, I'd be interested in understanding when that might happen. It does make sense but I don't understand when it would occur.  

  4.  ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog is
  terminated, procedures and resources associated with the ICE related
  in-band procedures for that dialog can be released.

In email you mentioned that it is the sending of keep alives that can be stopped. This is a good answer and makes sense. Can you update the text to say that and also mention how frequently they are sent and what sort of scenarios benefit from this optimization. 

  5.  Limited access resources - in case of forking and multiple stream
  it may not be possible to allow early media on all dialogs, so media
  sessions associated with some dialogs may e.g. be set to "inactive".
  When a dialog is terminated, media sessions associated with other
  dialogs can be allowed.

From email "[Christer] The probably most common scenario is when an application server in the network creates an early dialog with the UA in order to send an announcement, while the INVITE is forwarded towards the remote UA(s). There are specified procedures (in TISPAN and 3GPP) where this occur, and I believe this mechanism has also been discussed on the IETF SIP lists."

Can you help educate me about theses a bit more. The ones I saw before involved the announcement finishing before the PSTN got the call. 

  6.  Secure media selection - when SRTP is used to encrypt the media.

I'm still not following what this allows that would not be otherwise possible without the 199. I did read the Note about SRTP. 

I'm not understanding why 199 allows the SBC to do something it can not do today in the section where latching is discussed.  Typically "Latching" in SBC is not at all what you describe here. It is the process by which an SBC decide to send RTP to a IP address that is different than what is in the SDP. Can walk me through in email what is going on propose some text. 

In  the case of early ring tone termination where say a PSTN gateway roles over to voicemail, I don't see who this will accelerate the move in any useful way from the PSTN ringback tone to the voicemail server media.

I see no reason to allow this in a Require or proxy-Require and think that should be a MUST NOT. As you can tell, I think the value of this draft is somewhat limited but I am OK with publishing it as long as it does no harm. I view adding a require or proxy-require as something that would reduce interoperability of SIP call in a significant way and thus be harmful. I am very unlikely to be convinced to change my position on this one but I would be happy to hear concrete reasons why this needs to be a SHOULD.

It's unclear to me what Reason code to insert or why this is a MUST. The reason code seems non necessary for the describes uses of this mechanism. I read your email and it did not help me understand why the Reason was mandated. Mandating things that are not needed and can be separated seldom turns out to be good [as you rightly pointed out in putting the keep-alives in the same draft as rest of outbound]. Unless there is a compelling technical reason for this we should not do it. 

The actual specification of how you deal with SDP in a 199 containing an offer  is probably all correct in the draft but it is very difficult to understand the logic that lead to this and what one is supposed to do. Could you rephrase it be clear on exactly how this interacts with invites with no offer and explain why it needs to work the way it does. 

The not sending things reliably that have a Require: 100rel seems like it will break some IDS, firewalls, and middles boxes that are expecting any 1xx to reliable since that was signaled. I'd like to see text that helped explain this. I'm not asking you to change this - I am asking to discuss and point out the implications of if. 

I would like to see it very clear in the document at if you receive SDP in a 199, the UA MUST ceases sending all media on the RTP streams associated with that dialog. I would not want this to be used in an attack where one could send an an authenticated 199 and cause devices to star sending media to random 3rd parties that showed up in the SDP. 

I imagine more than one of these thing may just be talking past each other so I'm glad to have a phone call if that helps clear any of this up. I'm sure some rounds of email will be needed.

(Robert Sparks) (was Discuss, Yes) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Ross Callon) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2010-02-02 for -)
No email
send info
INTRODUCTION, paragraph 2:
>            Response Code for Indication of Terminated Dialog

  Add something to the title that makes it clear this is for SIP?

Section 3., paragraph 1:
>    REQ 1: It must be possible to indicate to the UAC that an early
>    dialog has been terminated before a final response is sent.

  I don't understand the purpose of including this single requirement in
  this specification document. At least not without further explanation.

(Adrian Farrel) No Objection

Comment (2010-02-02 for -)
No email
send info
The document does not say what track it is targeting. I assume from the
ballot that it is intended as Standards Track. Please can you confirm 
and update the document header.

The abbreviations UAC and UAS will need to be expanded in the Abstract
and on first usage in the body text.

(Russ Housley) No Objection

Comment (2010-01-29 for -)
No email
send info
  The Gen-ART Review by Avshalom Houri on 26 Jan 2010 suggested adding
  references to other relevant RFCs in the Security Considerations.  A
  few editorial changes were suggested.  Please consider these changes.

(Tim Polk) No Objection

Comment (2010-02-03 for -)
No email
send info
Section 1 states

   The 199 response code is an optimization, which allows the UAC to be
   informed about terminated early dialogs.  However, since the support
   of the 199 response is optional, a UAC cannot assume that it will
   always receive a 199 provisional response for all terminated early

Section 4 seems to imply that there are some applications that will not work unless 199
is supported:

 The UAC SHOULD NOT insert the 199 option-
   tag in the Require header, unless the particular session usage
   requires the UAS to support the response code.  Also, the UAC SHOULD
   NOT insert the 199 option-tag in the Proxy-Require header, unless the
   particular session usage requires every proxy on the path to support
   the response code.

Are these two sections in conflict?

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-03-01 for -)
No email
send info
The introduction is difficult to understand. It would be helpful to provide a picture of the scenario that motivates this document, or at least to provide a forward reference to the "swim lane" diagrams in Section 9.

(Sean Turner) No Objection

Comment (2011-03-02 for -)
No email
send info
#1) Sec 1: Can you provide an example of policy related decision?

   In addition, SIP entities might also use the 199 response to make
   policy related decisions related to early dialogs.

#2) Sec 5: This is a little hard to parse (it's all one sentence):

   If a UAS receives an initial dialog initiation request, with a
   Supported header field that contains a "199" option-tag, it SHOULD
   NOT send a 199 response on an early dialog associated with the
   request, before it sends a non-2xx final response, unless it e.g. has
   been configured to do so due to lack of support of the 199 response
   code by forking proxies or other intermediate SIP entities, or it is
   used in an environment that specifies that it shall send a 199
   response before sending a non-2xx response.

#3) I'm trying to reconcile the statement in the 2nd to last para of Sec 5, which says that the 199 is only for informational purposes, with the MUST NOT In the last paragraph.  If it's informational then why is it a MUST NOT?

Magnus Westerlund No Objection

Alexey Melnikov Abstain

Comment (2011-03-03 for -)
No email
send info
I agree that Experimental for this document is going to be better.

I don't think the document is doing a very good job convincing readers about utility of this mechanism. At least not until it starts describing detailed use cases.

4.1.  Examples of resource types

   NOTE: When using SRTP [RFC3711], the secure media stream is bound to
   the crypto context setup for the dialog, and can be identified using
   the MKI (if used) of SRTP.

Please expand the acronym on first use.

   If the client only has a single early dialog (other early dialogs MAY
   not have been established, or they MAY have been established and

It doesn't look like use of these 2 MAYs is correct - they don't describe requirements.

   later terminated) and a 199 response is received for that early
   dialog, the client terminates the early dialog.  Afterwards, the
   client SHOULD act as before the first early dialog was established.

4.2.  Examples of policy procedures

   2.  SBC early media selection - when an SBC is used to control which

Please expand the acronym on first use.

   media is processed and forwarded.  In many cases, the SBC only
   processes media associated with a single early dialog.  Typical for
   NAT traversal, the SBC often "latches" onto a media stream.  If a 199
   response is received, the SBC can choose to start processing media
   associated with another dialog.  If the SBC performs latching, it can
   trigger a "re-latch" onto a new media stream when the 199 response is