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
