hi, I don't think the 199 can be sent unreliably if UAC require 100rel. As in RFC3262, It says.
The UAS MUST send any non-100 provisional response reliably if the initial request contained a Require header field with the option tag 100rel. If the UAS is unwilling to do so, it MUST reject the initial request with a 420 (Bad Extension) and include an Unsupported header field containing the option tag 100rel. Regards, Eric 2009/2/27, Christer Holmberg <[email protected]>: > > Hi, > > >If the UAC requires 100rel ,then what should the proxy do if it receives > a no-2xx final response after forking? > > The proxy should send 199 unreliably. > > Regards, > > Christer > > > > > 2009/2/27, Christer Holmberg <[email protected]>: >> >> Hi, >> >> >Practically, when Call forward and fork are used in the same system, >> there are >> >lots of early dialogs that should be eliminated by 199 existed. >> >So I think that it's useful to let 199 reliable. >> >And we just added fork-service to our system ,and find 199 is really >> useful, and >> >if the 199 is missing, problems will happen. >> >> I'm glad you think 199 is useful :) >> >> But, if a proxy would have to terminate PRACKs etc it would not be a proxy >> anymore - it would be a B2BUA. >> >> So, if you really want your network to send 199 reliably, I guess you >> could use a B2BUA instead of a proxy. >> >> >It sounds good that there is a way to prevent PRACK addressed to UAS,but >> i don't know how to do now. >> >> The only way to prevent it is by the proxy not sending the 199 relaible. >> >> >> >ps: >> >RFC3261 *16.7 Response Processing* >> >Since a proxy may not insert a tag into the To header field of >> >a 1xx response to a request that did not contain one, it cannot >> >issue non-100 provisional responses on its own. >> >> Yes, but I we have agreed that a proxy is allowed to send 199. >> >> But, the proxy is not going to generate new To header tag values for the >> 199. It will use whatever tags that have already been created for the early >> dialogs. >> >> Regards, >> >> Christer >> >> >> >> >> >> >> >> >> >> >> *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. >> >> Paul >> >> [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 >> >> >> >> >> -------------------------------------------------------- >> 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
