We could write in an RFC that lead must be turned into gold, but when itcame time to implement that it would be discovered that it wasn'tfeasible to always follow the RFC. The quotes below reflect a similar degree of naivety in 3262, at leastregarding the responses to PRACK. Plenty of examples have been given ofcases where it is inappropriate to return a 200 response. The statement that retransmissions shall cease when the matching PRACKis received is, IMO, predicated on the assumption that a 200 will alwaysbe returned. Once you reverse that assumption, then you must alsoreconsider this statement. Thanks, Paul gao.yang2@xxxxxxxxxx wrote:> > More points of view to this question:> > By RFC3262:> 1. "Retransmissions of the reliable provisional response cease when a > matching PRACK is received by the UA core."> > 2. "If the PRACK does match an unacknowledged reliable provisional > response, it MUST be responded to> with a 2xx response."> > So, when UAs receive a matching PRACK, it will stop re-transmit the > reliable provisional response(18x). And the response> to PRACK MUST be 2xx.> > It is simple and clear. And when UAs receive non-2xx response to PRACK, > it is clear that the other side do not receive the> PRACK. It can send a new PRACK(CSeq++, the same RAck).> > And now, we can use PRACK to send "precondition notification" and "codec > refine". When we need to issue session modification like adding codec,> adding/removing media streams, we MUST using Re-INVITE/UPDATE.> > I think we should not re-write RFC3262 to allow the UA to reject the PRACK.> > > > > > *Paul Kyzivat <pkyzivat@xxxxxxxxx>*> 发件人: sipping-bounces@xxxxxxxx> > 2009-04-06 20:16> > > 收件人> "Rockson Li (zhengyli)" <zhengyli@xxxxxxxxx>> 抄送> sipping@xxxxxxxx, Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>> 主题> Re: PRACK: Change MUST requirement to include SDP offer in > first reliable provisional response> > > > > > > > > I think I also agree. There are a lot of things that in hindsight we> probably would have done differently. But that is water over the dam. We> are where we are.> > Paul> > Rockson Li (zhengyli) wrote:> > I totally agree with Hadriel's insight here.> >> > It should have been avoided to put too many jobs into PRACK,> >> > I miss KISS(Keep It Simple and Stupid) principle> >> > > >> > Regards,> >> > -Rockson> >> > ------------------------------------------------------------------------> > *From:* sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] *On> > Behalf Of *Hadriel Kaplan> > *Sent:* Tuesday, March 31, 2009 9:50 PM> > *To:* Christer Holmberg; sipping@xxxxxxxx> > *Subject:* Re: [Sipping] PRACK: Change MUST requirement to include SDP> > offer in first reliable provisional response> >> > > >> > > >> > In hindsight I’m thinking we probably also shouldn’t have made the SDP> > answer (or another offer) required or even possible in the PRACK> > either. I think it should have been for one and only one purpose: to> > acknowledge receipt of the provisional response.> >> > > >> > -hadriel> >> > > >> > > >> >> > ------------------------------------------------------------------------> >> > _______________________________________________> > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping> > This list is for NEW development of the application of SIP> > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip> > Use sip@xxxxxxxx for new developments of core SIP> _______________________________________________> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping> This list is for NEW development of the application of SIP> Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip> Use sip@xxxxxxxx for new developments of core 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._______________________________________________Sipping mailing list https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP
