hi, If the UAC requires 100rel ,then what should the proxy do if it receives a no-2xx final response after forking?
Regards, Eric 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
