Subject: [Sip] I-D Action:draft-ietf-sip-199-06.txt

From: [email-masked]
Date: Mon, 2 Mar 2009 04:15:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title           : Response Code for Indication of Terminated Dialog
	Author(s)       : C. Holmberg
	Filename        : draft-ietf-sip-199-06.txt
	Pages           : 14
	Date            : 2009-03-02

This specification defines a new SIP response code, 199 Early Dialog
Terminated, which a SIP forking proxy and a UAS can use to indicate
upstream towards the UAC that an early dialog has been terminated,
before a final response is sent towards the UAC.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-199-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Bob Penfield <[email-masked]>
Date: Tue, 3 Mar 2009 19:57:53 -0500

Hi Christer,

I have few comments on draft-ietf-sip-199-06.txt. I apologize if any of these are duplicates.

Section 6. The statement requiring the proxy to keep track of early dialogs:

   A proxy which supports generating of 199 response codes MUST keep
   track of early dialogs, in order to determine whether to generate a
   199 response when the proxy receives a non-2xx final response.  In
   addition, the proxy MUST keep track on which early dialogs it has
   received and forwarded 199 responses, in order to not generate
   additional 199 responses for those early dialogs.

Should precede the statement:

   If the forking proxy generates a 199 response, and if the
   forking proxy is able to identify additional early dialogs which are
   terminated by the same non-2xx final response, it MUST also generate
   and send a 199 response upstream for each of those early dialogs,

In fact, if the proxy is keeping track of early dialogs, under what
circumstances would it not be "able to identify additional early
dialogs which are terminated by the same non-2xx final response"?

Section 8 (199 Early Dialog Terminated) seems out of place. Shouldn't
this be in the introduction? or in an "Overview Of Operation" between
sections 3 and 4?

The text in Section 9 (Usage with SDP offer/answer) should be in
section 5 (User Agent Server behavior).

The statement in section 10 recommending that the UAS send 199
unreliably should be in section 5.

The statement in section 10 forbidding proxies from sending 199
reliably should be in section 6 (Proxy behavior).

Cheers,
(-:bob

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 5 Mar 2009 10:10:54 +0100

Hi Bob,
 
>    forking proxy is able to identify additional early dialogs 
>    which are terminated by the same non-2xx final response, it MUST 
>    also generate and send a 199 response upstream for each of those
early dialogs,
> 
>In fact, if the proxy is keeping track of early dialogs, 
>under what circumstances would it not be "able to identify 
>additional early dialogs which are terminated by the same 
>non-2xx final response"?

Just because the proxy keeps track of early dialogs, it doesn't
necessarily know that an error response on early dialog X also
terminates early dialog Y. In order to know that, the forking proxy
needs to know that early dialogs X and Y come from the same forking
proxy further down the path.

>Section 8 (199 Early Dialog Terminated) seems out of place. 
>Shouldn't this be in the introduction? or in an "Overview Of 
>Operation" between sections 3 and 4?

I have tried to use other similar drafts as "template".

>The text in Section 9 (Usage with SDP offer/answer) should be 
>in section 5 (User Agent Server behavior).

I think it is good to have a separate chapter. Of course, I could refer
to chapter 9 from chapter 5.

>The statement in section 10 recommending that the UAS send 
>199 unreliably should be in section 5.
> 
>The statement in section 10 forbidding proxies from sending 
>199 reliably should be in section 6 (Proxy behavior).

Same as for offer/answer.

Since the 199 procedures related to offer/answer and reliable responses
are special, I think it is good to have specific chapters for it.

Regards,

Christer

---

From: Bob Penfield <[email-masked]>
Date: Thu, 5 Mar 2009 10:30:40 -0500

inline

>-----Original Message-----
>From: Christer Holmberg [mailto:[email-masked]]
>Sent: Thursday, March 05, 2009 4:11 AM
>To: Bob Penfield
>Cc: [email-masked]
>Subject: RE: [Sip] I-D Action:draft-ietf-sip-199-06.txt
>
>
>Hi Bob,
>

Of course it can. If the proxy forwarded the request to Z, and Z forked
to X and Y, the provisional responses from X and Y that created the
early dialogs would have the same branch-id. The error response from Z
would have that same branch-id. The proxy would know that all early
dialogs created by a 1xx with that branch-id would have terminated
(i.e. both X and Y).

>to chapter 9 from chapter 5.

My point is that all too often behavior requirements (MUST, SHOULD,
MAY, etc.) get buried is separate sections and folks can miss
them. If all the requirements are in the applicable "behavior"
section, they are easy to find and developers are less likely to miss
them. If you want it to be a separate section, make it 5.1. All UAS
requirements should be in section 5 or a subsection thereof.

>are special, I think it is good to have specific chapters for it.

The requirements/restrictions for reliable provisional responses are
very important. They could easily be missed by having them in a
separate chapter in the back of the document. Again, all UAS behavior
requirements should be in section 5 (or sub-section) and all proxy
behavior requirements should be in chapter 6 (or sub-section).

>Christer

cheers,
(-:bob

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 11 Mar 2009 14:20:06 +0100

Hi Bob, 

>Of course it can. If the proxy forwarded the request to Z, 
>and Z forked to X and Y, the provisional responses from X and 
>Y that created the early dialogs would have the same 
>branch-id. The error response from Z would have that same 
>branch-id. The proxy would know that all early dialogs 
>created by a 1xx with that branch-id would have terminated 
>(i.e. both X and Y).

But, the branch-id is part of the Via, which is removed by each entity
when forwarding the response. So, the forking proxy is never going to
get the branch-id inserted by Z, is it?

>My point is that all too often behavior requirements (MUST, 
>SHOULD, MAY, etc.) get buried is separate sections and folks 
>can miss them. If all the requirements are in the applicable 
>"behavior" section, they are easy to find and developers are less
likely 
>to miss them. If you want it to be a separate section, make 
>it 5.1. All UAS requirements should be in section 5 or a 
>subsection thereof.
>
>The requirements/restrictions for reliable provisional 
>responses are very important. They could easily be missed by 
>having them in a separate chapter in the back of the 
>document. Again, all UAS behavior requirements should be in 
>section 5 (or sub-section) and all proxy behavior 
>requirements should be in chapter 6 (or sub-section).

I'll think of something. But, as you ok with the text as such? It's only
the location of the text which you have an issue with?

Regards,

Christer

---

From: Bob Penfield <[email-masked]>
Date: Tue, 24 Mar 2009 02:45:07 -0400

The proxy only needs to use the top Via that it inserted.

The proxy needs to keep a list of early dialogs associated with each client transacton. As part of that early dialog state, it needs to have a flag to indicate whether or not a 199 was received and forwarded by the proxy so that no more than one 199 response is sent for a given dialog. When a 1xx response that creates an early dialog is received, the proxy adds the early dialog to the list (if it has not already). When the non-2xx final response is received, it can generate 199 responses for each early dialog in the list which has not already had a 199 sent.

________________________________________
From: Christer Holmberg [[email-masked]]
Sent: Wednesday, March 11, 2009 9:20 AM
To: Bob Penfield
Cc: [email-masked]
Subject: RE: [Sip] I-D Action:draft-ietf-sip-199-06.txt

Hi Bob,

likely

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Mar 2009 08:07:09 +0100

Hi,

>The proxy needs to keep a list of early dialogs associated with each client transacton. As part of that 
>early dialog state, it needs to have a flag to indicate whether or not a 199 was received and forwarded by 
>the proxy so that no more than one 199 response is sent for a given dialog. When a 1xx response that creates 
>an early dialog is received, the proxy adds the early dialog to the list (if it has not already). When the 
>non-2xx final response is received, it can generate 199 responses for each early dialog in the list which 
>has not already had a 199 sent.

Yes, but the issue is how the proxy knows whether it has sent a 199 for the early dialog indicated in the error response.

The issue is whether the proxy can detect that a final response is generated by another forking proxy, and therefor terminate more than one early dialog.

Maybe the Via mechanism you describe works... I need to draw some figures :)

Regards,

Christer

_______________________________________
From: Christer Holmberg [[email-masked]]
Sent: Wednesday, March 11, 2009 9:20 AM
To: Bob Penfield
Cc: [email-masked]
Subject: RE: [Sip] I-D Action:draft-ietf-sip-199-06.txt

Hi Bob,

likely

Regards,

Christer

---

From: Bob Penfield <[email-masked]>
Date: Tue, 24 Mar 2009 12:35:35 -0400

>dialog indicated in the error response.

Again, the proxy needs to have a list of early dialogs and within that state data needs to remember whether or not a 199 has been sent/forwarded to the UAC.

>
>The issue is whether the proxy can detect that a final response is generated by 
>another forking proxy, and therefor terminate more than one early dialog.

It does not matter whether the final response came from a forking proxy or not. When a final response is received on a client transaction, the proxy has to assume that all downstream forks that the request created have been terminated. RFC 3261 requires that the proxies and UASes send only one non-2xx final response, so any downstream proxy that forked the request would not send back a non-2xx final response until all of its forks completed.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Mar 2009 17:41:02 +0100

Hi, 

>>Yes, but the issue is how the proxy knows whether it has sent a 199
for the early dialog indicated in the error 
>>response.
>
>Again, the proxy needs to have a list of early dialogs and within that
state data needs to remember whether or not a 199 
>has been sent/forwarded to the UAC.

Again, I agree with you :)

>>The issue is whether the proxy can detect that a final response is 
>>generated by another forking proxy, and therefor terminate more than
one early dialog.
>
>It does not matter whether the final response came from a forking proxy
or not. When a final response is received on a 
>client transaction, the proxy has to assume that all downstream forks
that the request created have been terminated. RFC 
>3261 requires that the proxies and UASes send only one non-2xx final
response, so any downstream proxy that forked the 
>request would not send back a non-2xx final response until all of its
forks completed.

Yes, and the issue was HOW the proxy knows WHICH downstream forks are
terminated by the single final response. Your proposal is to look at the
Via branch, and I think that may work.

So, I think we're on the same page :)

Regards,

Christer