Hi Paul, >*allowing* (much less *requiring*) the 199 to be reliable introduces nasty >problems. The 199 is only an optimization, so having it be unreliable is ok >IMO. > >The problem is that if a proxy sends the 199, then the recipient of the PRACK >should be the proxy. But the PRACK is an in-dialog message, so it must be >addressed to the Contact of the UAS. > >If the proxy sends a reliable 199, and the PRACK is addressed to the UAS, the >UAS will be very surprised, since it has not send a reliable provisional, and >is so not expecting a PRACK. In fact, it has >sent a final response, has presumably already received the ACK, and so is >expecting nothing. > >Very ugly.
Just to clarify, a proxy MUST NOT send it reliably. The text in chapter 10 says: "When a forking proxy generates a 199 response, the response MUST NOT be sent reliably." The reason is, as Paul indicated, that the proxy would need to terminate the PRACK. A UAS is allowed to send 199 reliably, but the tex says that it SHOULD be sent unreliably. Regards, Christer [email protected] wrote: > > Hi, > > And there still two questions left. > > 1. Is the 199 should be reliable or unreliable? > I think that 199 should be reliable if possible. > > > First, If a client receives an unreliable 199 response on a dialog > which has > not previously been created (this can happen if a 199 response > reaches the client before a 18x response) the client SHALL discard > the 199 responses. > > The figure below shows an example.The 180 is sent first but arrives > later than 199. > If the 199 is reliable, the proxy should retransmit 199 (step 4),and > then the retransmitted > 199 will be accepted by UAC,and the early dialog will be teminated. > > UAC P > 1. INVITE > ---------------> > 2. 180 > <----- \/------- > /\ 3. 199 > <-----/ \------ > 4. 199(retransmitted) > <--------------- > > second, According to practical use, 199 can be intended to teminate > one early dialog and release resources associated with the specific > early dialog, so the cost spent on reliable 199 is worthy. > If the 199 cannot be sent reliable,then we should send it unreliable. > > 2. In your last letter, you said "the second 199 could include > information which is to be forwarded to the UAC", then do you mean, > the early dialog is still alive after the first > 199 is accepted? > > > Also, In my last letter, I miss a "NOT" by mistake. > It should be > [Eric]: Surely the UAS is NOT allowed to send another reliable > response until the first one is acknowledged... > > Regards, > Eric wang > > > > > *"Christer Holmberg" <[email protected]>* > > 2009-02-27 03:04 > > > 收件人 > "Eric wang" <[email protected]> > 抄送 > <[email protected]>, <[email protected]> > 主题 > RE: Questions about "draft-ietf-sip-199-05" > > > > > > > > > Hi, > > >I still have some difficult in using IETF and cannot find the whole > sorted comments about this draft, so i have some doubt about this draft. > > > > 1. "If a forking proxy receives a reliably sent 199 response for a > dialog, for which the proxy has previously generated and sent a 199 > response, the proxy MUST forward the 199 response." > > > > Does it describe the case below? Although P1 have sent a 199 > response, P1 havs to forword the send reliably 199 too.Or is the > first 199 mistaked for 18x? > > > > UAC P1 UAS_2 > > --- INVITE ------> > > --- INVITE (leg 2) -> > > <-- 199(leg 2) -- > > <-- 199 (leg 2) ----- > > <-- 199(leg 2) -- > > >I think it shall be 199, as currently written. > > > >[Eric]: If this is 199, then Is there a special purpose to send two > 199 in the same dialog? > >I think that one 199 is enough. > >And the first 199 may be reliable too, that will make it a little > difficult to send the second 199. > > The second 199 could include information which is to be forwarded to > the UAC. > > > >2. "10. Usage with 100rel > > > > When a 199 Early Dialog Terminated provisional response is sent by a > UAS, since the provisional response is only used for information > purpose, the UAS SHOULD send it unreliably even if the 100rel > > option tag [RFC3262] is present in the Require header of the > associated request." > > > > > >I have seen a comment on this question,but still not understood > about >it. If the INVITE has a Require tag "Require: 100rel",does the > UAS still >use unreliable 199 response? > > > >That is the recommendation, yes. The reasons is that we want to keep > 199 > >as "lightweight" as possible, without requireing re-transmissions > and >PRACKs. > > > >[Eric]: But reliable 199 have more advantage, and It is worth to use > the reliable 199,I think. > > I don't know what that advantage would be, compared to having to send > PRACKs etc. This has been discussed quite much, so I would really need > some good justification to change it now. > > Also, the draft doesn't forbid you to send the 199 reliably. It's only > a SHOULD. > > > >If 199 is reliable, there is one more advantage. If the 199 arrives > >before the first 18x response, UAC can discard the first 199 and > process >it until UAC receives the first 18x response that has the > same >to-tag as 199, as the reliable 199 should be re-transmited > until >received PRACK. > > > >If the INVITE contains "Require: 100rel", the first 18x must also be > >sent reliably. And, I don't think the UAS is allowed to send another > >reliable response until the first one is acknowledged, so I don't > think >a reliable 199 would reach the UAC before the first reliable 18x. > > > >[Eric]: Surely the UAS is allowed to send another reliable response > until the first one is acknowledged, > > If I remember correctly, the FIRST reliable response must be > acknowleded before the next reliable response is sent. But, we can > double check in the PRACK spec. > > >but reliable 199 will be useful if the first 18x is unreliable, or > the first 18x has been acknwledged. It's another case different from > the above one whose INVITE contains "require: 100rel". > > If 100rel is required the 18x cannot be unreliable. > > Regards, > > Christer > > > > > > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy and > are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. If > you have received this email in error please notify the originator of the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > 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
