Hi, Maybe we could talk about the case when a UAS establishes more than one dialog? Regards, Christer
________________________________ From: [EMAIL PROTECTED] on behalf of Paul Kyzivat Sent: Sat 14/06/2008 23:35 To: Attila Sipos Cc: [email protected] Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Attila, Sure we can take the approach of leaving it to the UAS to decide whether to send a 199. My concern is that it may be inefficient, not just for that UA, but for the system as a whole. So I think we need to be a little careful here. I'm not suggesting forbidding this - clearly there are cases where it is the right thing to do. Paul Attila Sipos wrote: > > >>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 > > > > . > _______________________________________________ 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
