Dear Christer,
It seems I’d better review all your comments firstJ. Thank you for answering my question. Best regards, Eric 发件人: Christer Holmberg [mailto:[email protected]] 发送时间: 2009年2月27日 19:22 收件人: Eric wang 抄送: [email protected]; Paul Kyzivat; [email protected] 主题: RE: [Sip] 答复: RE: Questions about "draft-ietf-sip-199-05" 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. This has been discussed, and the proposed outcome was to allow 199 to be sent unreliably even if 100rel is required. Regards, Christer 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
