Re: I-D Action:draft-ietf-sip-199-06.txt

Hi,

 
>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.

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 protected]]
Sent: Wednesday, March 11, 2009 9:20 AM
To: Bob Penfield
Cc: [email protected]
Subject: RE: [Sip] I-D Action:draft-ietf-sip-199-06.txt

Hi Bob,

>>>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.
>>
>
>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?


>>>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.
>
>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 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.
>>
>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

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip