Hi, ________________________________
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Friday, February 27, 2009 3:06 AM To: Christer Holmberg Cc: [email protected] Subject: [Sip] 答复: RE: Questions about "draft-ietf-sip-199-05" Hi, > 1. Is the 199 should be reliable or unreliable? SHOULD be unreliable (if sent from a UAS). >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) ><--------------- In my opinion it would be much wiser to send the 180 relaibly in this case, and then send 199 once the 180 has been acknowledged. >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? No. But there has been discussions to e.g. include the error response which triggered the 199, so that the UAC gets more information on WHY the early dialog was terminated. Regards, Christer "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
