I can think of one scenario... If the UAS in question is actually some sort of B2BUA.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Paul Kyzivat > Sent: Friday, June 13, 2008 07:07 > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > This all sounds like good stuff. > > However I am still scratching my head about the UAS sending a > 199. While I see no reason to forbid it I'm trying to find a > situation when it would be helpful. The only case I have been > able to think of is: > > There is a forking proxy upstream of the UAS, but it doesn't > support 199. Yet it may delay the final response while it > tries other forks. So the UAS sending the 199 makes up for > the inadequacy of the forking proxy. > > The trouble with this is that it is inefficient in many > cases. If each proxy that forks also supports the sending of > 199, and the UAS doesn't send one, then we avoid sending the > message except in cases where it is helpful. If the UAS > always sends it we have increased the message count by one > for all failing calls. And the majority of failing calls get > no benefit from a 199. > > This is one of those cases that could probably benefit from > simulation to judge the merits. My gut feel is that the costs > of the UAS sending the 199 outweigh the benefits. Barring > some analysis to the contrary I think I would say that a UAS > SHOULD NOT send a 199. Or perhaps MAY send, but without any > guidance of when. > > Paul > > [EMAIL PROTECTED] wrote: > > Here are some comments on this I-D. I don't think that any of them > > modify our understanding of the proposal. I guess this is > very terse; > > please use these suggestions as you see fit. > > > > * Abstract > > > > Clarify: > > > > This specification defines a new SIP response code, 199 Early > > Dialog Terminated, which a SIP entity can use to > indicate upstream > > that an early dialog has been terminated. The response > code can be > > used by a SIP entity (a SIP proxy or UAS), to inform the UAC that > > an early dialog has been terminated. As the 199 response is a > > provisional response, often the UAC will receive it before > > receiving a final response to its request. > > > > * Section 1 > > > > When a forking proxy receives a non-2xx final response, > it does not > > always immediately forward the response upstream towards > the sender > > of the associated request. Instead, the forking proxy > "stores" it > > and waits for further final responses from remote > destinations where > > the forked request was forwarded. > > > > The text does not allow for serial forking, only parallel forking, > > which might be confusing to people who are more aware of serial > > forking. So amend the last sentence to: > > > > Instead, the forking proxy "stores" it and waits for > further final > > responses from remote destinations where the forked request was > > forwarded, and possibly forwards the request to additional > > destinations. > > > > Also, Avoid using "..." except when indicating that the > word is used > > in a non-standard way or that one is discussing the word itself: > > > > Instead, the forking proxy "stores" it [...] > > > > should be: > > > > Instead, the forking proxy stores it [...] > > > > * Section 3. > > > > REQ 1: It must be possible to indicate to the UAC that an early > > dialog has been terminated before a final response is sent. > > > > Oddly, though everyone thinks they understand this sentence, it > > doesn't really say what we want. To really ensure that the UAC > > understands the early dialog has been terminated before the > UAS sends > > a final response, the UAS would have to send 199 *and get the PRACK > > saying that it was received* before sending a final response. This > > may well be worse than the present state of affairs. > > > > What we really mean is: > > > > REQ 1: It must be possible for a UAS or proxy to send an > indication > > to the UAC that an early dialog has been terminated, which > > indication will not be delayed waiting for a final response from > > any UAS. > > > > * Section 4 > > > > When a client receives a 199 Early Dialog Terminated provisional > > response it MAY release resources and procedures > associated with the > > early dialog the 199 response is received on. > > > > Amend to clarify the meaning of 199 independently of the > consequences > > of that meaning: > > > > When a client receives a 199 Early Dialog Terminated provisional > > response, it has positive knowledge that the UAS that created the > > early dialog has terminated it, and so the client MAY release > > resources and procedures associated with the early > dialog for which > > the 199 response is received. > > > > * Section 4 > > > > Add this paragraph before the last paragraph: > > > > A UAC that receives a 199 response for an early dialog MUST NOT > > send any further requests on that dialog, except for a > PRACK if the > > 199 response was sent reliably, and PRACKs for other reliable > > provisional responses that are to be acknowledged. > > > > This is copied from section 7 (Backward Compatibility), but > since it > > is a constraint on UACs, it should also be stated in this section. > > > > * Section 4 > > > > The UAC MAY use additional information (for example the final > > response which triggered the 199 response) received in the 199 > > response when initiating new sessions, if it is possible > to avoid the > > new session initiation request to be rejected. > > > > What is the meaning of the final clause? > > > > * Section 5 > > > > Add "early" as marked: > > > > When a UAS wants to terminate *an early* dialog it sends > a non-2xx > > SIP final response, as specified in [RFC3261]. In > addition, prior > > to sending the non-2xx SIP final response, the UAS MAY send a 199 > > response to indicate that the dialog is being terminated. > > > > This clarifies that 199 cannot be used to terminate a confirmed > > dialog. > > > > (The reason a UAS may want to send a 199 is to provide this > > information even when the upstream proxy does not support 199.) > > > > There is a subtlty to the second sentence: > > > > Sending the 199 *before* the final response is not necessary due to > > the semantics of 199 (as it will probably reach the UAC > first anyway, > > and it would not matter if it did not), but rather to prevent the > > upstream proxy from generating a 199 based on the final > response, and > > then to transmit the UAS's 199 immediately after -- if the > UAS sends > > the 199 first, any upstream proxy will (most likely) see the 199 > > before seeing the final response (which might induce the > proxy to send > > its own 199). > > > > * Section 6 > > > > When a forking proxy receives a non-2xx final response which > > terminates one or more early dialogs and the proxy does > not intend to > > forward the final response immediately (due to the rules for a > > forking proxy) it MUST send a 199 provisional response, for each > > associated early dialog that it can associate with the final > > response, upstream towards the sender of the associated request. > > > > Clarify, and note that if the proxy has already passed a 199 for an > > early dialog, it need not generate one itself. Also, I've reduced > > MUST to SHOULD, because (as the following NOTE explains), the proxy > > may not know of all early dialogs which are terminated by the final > > response. > > > > [...] it SHOULD initiate a 199 provisional response upstream > > towards the sender of the associated request, for each terminated > > early dialog, excepting those for which it has already > transmitted > > a 199 response. > > > > Note that the "already transmitted 199 responses" may have > come from > > downstream proxies as well as downstream UASs, so this > consideration > > applies even if we do not allow UASs to send 199s. > > > > * Section 7 > > > > Since all SIP entities involved in a session setup do > not necessarily > > support the specific meaning of the 199 Early Dialog Terminated > > provisional response, the sender of the response MUST be > prepared to > > receive SIP requests associated with the dialog for which the 199 > > response was sent. > > > > This situation can also result due to race conditions. Amend to: > > > > Because of race conditions and because the client may > not support the > > specific meaning of the 199 provisional response, the > sender of the > > response MUST be prepared to receive SIP requests associated with > > the dialog for which the 199 response was sent. > > > > And add a qualifier to this sentence: > > > > If such request is received, and the receiver maintains state of > > the dialogs, the receiver MUST reply to such requests with a 481 > > final response (unless another error response is more > appropriate). > > > > * Section 7 > > > > Remove "..." from this sentence and add "even" as marked: > > > > The 199 Early Dialog Terminated response code MUST NOT replace a > > final response. A final response MUST always be sent, > *even* after > > one or many 199 Early Dialog Terminated provisional > responses have > > been sent. > > > > * Section 8 > > > > Clarify this sentence to: > > > > The 199 Early Dialog Terminated response code allows a SIP entity > > to indicate to upstream entities that a specific early dialog has > > been terminated, before a final response reaches the upstream > > entities. > > > > Add the following: > > > > The early dialog that has been terminated is identified > by the Call-Id > > header and the to-tag value of the 199 response. > > > > Future standards may define optional additional > information carried > > in the headers and/or body of the response. > > > > * Section 9 > > > > A 199 Early Dialog Terminated provisional response MUST > NOT contain a > > new SDP offer/answer message body, but the sender of the > response MAY > > insert a copy of a previously sent offer/answer message body as > > otherwise allowed by the offer/answer rules for a provisional > > response. > > > > This rule seems excessively strict, as it seems OK to send > a new SDP > > answer in a 199, even if the dialog will be immediately terminated. > > Certainly, the UAC cannot tell the difference, as there could have > > been a previous but lost 1xx response carrying the same SDP. > > > > The interaction of 199 and SDP probably needs further study... > > > > * Section 11 > > > > Nit: Use "reject" here rather than "rejects": > > > > UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx > error response. > > > > Here is a modification of the example, showing how a UAS can send a > > 199, and how the proxy handles it. (You may or may not want to use > > this.) I've also added the ACK's for the 4xx's, which were > missing in > > the original. > > > > [...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error > > response. UAS_3 sends a 199 with its 4xx. When P1 receives the > > 4xx response from UAS_2 it immediately sends a 199 Early Dialog > > Terminated associated with UAS_2's dialog towards the UAC. P1 > > transmits UAS_3's 199, and so does not initiate one itself for > > UAS_3's dialog when it receives UAS_3's 4xx response. > > > > UAC P1 UAS_2 UAS_3 UAS_4 > > > > --- INVITE ------> > > --- INVITE (leg 2) -> > > --- INVITE (leg 3) ----------> > > --- INVITE (leg 4) -------------------> > > <-- 18x (leg 2) ----- > > <-- 18x (leg 2) -- > > <-- 18x (leg 3) -------------- > > <-- 18x (leg 3) -- > > <-- 18x (leg 4) ----------------------- > > <-- 18x (leg 4) -- > > <-- 4xx (leg 2) ----- > > <-- 199 (leg 2) -- > > --- ACK (leg 2) ----> > > <-- 199 (leg 3) -------------- > > <-- 199 (leg 3) -- > > <-- 4xx (leg 3) -------------- > > --- ACK (leg 3) -------------> > > <-- 200 (leg 4) ----------------------- > > <-- 200 (leg 4) -- > > --- ACK (leg 4) -> > > --- ACK (leg 4) ----------------------> > > > > Dale > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 > _______________________________________________ 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
