Hi, >We have a query on our basic understanding of this draft. > >I too had the same query as Ashish, I can rephrase it for all of us. >What we mean to ask is that, considering the scenario shown by the SIP msg >flow below, at what point does the proxy decide to send 199 response and on >which call legs.
A proxy would send a 199 as soon as it receives a final non-2xx response for a leg. >For e.g. in the scenario below, when proxy receives 403 on leg 2, and it is >yet to receive responses on leg 3 and 4. In this case, the proxy cannot send a >199 to the UAC (is my understanding, >please correct if wrong). Yes, it can send 199 for leg 2. In SIP you can send as many provisional responses as you want. >Also after having received 5xx and 6xx on the leg 3 and 4, there is no use >sending 199 now because the best final response sent to UAC is sufficient to >indicate that the leg 3 and 4 are >terminated. If the proxy is going to send a best final response immediately there is no need to send 199. But, if the proxy is still waiting for final responses, it would send 199. Regards, Christer ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christer Holmberg Sent: Monday, June 16, 2008 1:42 PM To: Ashish Saxena (WT01 - Telecom Equipment); [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Hi, The way the "best" final response code is chosen is described in RFC 3261, and the intention of 199 is not to change that. Regarding whether a 199 will be sent for leg 4: if the proxy is now going to send a "best" final response I guess it doesn't need to send 199 for leg 4. Regards, Christer ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 16. kesäkuuta 2008 10:32 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Referring to introduction part in the draft. " At some point the proxy uses a specified mechanism to determine the "best" final response code, and forwards that final response upstream towards the sender of the associated request." Considering a scenario where all the forks have failed in yielding a 2xx response from different UASes (UAS2 , 3 & 4 in the diagram) with different error codes, how will the proxy determine the "best" final response and to which leg would it send the best final response. What would happen after 199 to leg 4? 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) -- <-- 5xx (leg 3) -------------- <-- 199 (leg 3) -- <-- 6xx (leg 4) ----------------------- <-- 199 (leg 4) -- Best Regards, Ashish Saxena 877-5570 ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Attila Sipos Sent: Saturday, June 14, 2008 9:30 PM To: Paul Kyzivat; [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 >>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. It may or may not be helpful but as you say, you can see no reason to forbid it. Why restrict it if the restriction isn't needed? As someone has pointed out, a B2BUA scenario might benefit from 199. In fact, any kind of SIP gateway might benefit. > 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. If the UAS wants to send it, that is a decision for them - not something that needs to be prevented. SIP forking, in the technical sense of sending a response with a different to-tag, is always legal. So, any UA which has used forking should also be able to use 199. I don't think we need to include any specific text about UAS except to say that a UAS can use it if the UAS has created the forking. Regards, Attila -----Original Message----- From: [EMAIL PROTECTED] on behalf of Paul Kyzivat Sent: Fri 13/06/2008 15: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 . Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ 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
