We already know that one. I was asking if there are any others. Hisham 2009/4/2 Rockson Li (zhengyli) <zhengyli@xxxxxxxxx>: > > > -----Original Message----- > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Hisham Khartabil > Sent: Thursday, April 02, 2009 9:37 AM > To: Paul Kyzivat (pkyzivat) > Cc: sipping@xxxxxxxx; Christer Holmberg > Subject: Re: PRACK: Does non-200 response cease re-transmission ofreliable 18x? > > That's a good scenario. Any others? > > The point of the PRACK is to indicate to the UAS that the 1xx it sent was received successfully. Unless its a 401 to the PRACK, I don't see any other reason why the UAS should continue retransmitting the 1xx if its sent a non 2xx reponse to a PRACK. The PRACK has served its purpose. > > Having said that, what other reasons would a UAS reject a PRACK? > [RL] authentication. > https://lists.cs.columbia.edu/pipermail/sip-implementors/2009-March/022095.html > > Hisham > > 2009/4/1 Paul Kyzivat <pkyzivat@xxxxxxxxx>: >> >> >> Christer Holmberg wrote: >>> >>> Hi, >>> >>> One of the PRACK related issues presented in SFO is whether a PRACK >>> non-200 response would cease re-transmission of the assoicated >>> reliable 18x response. >>> >>> Based on the mail discussions we've had I proposed that the non-200 >>> response DOES NOT ceasee the re-transmission. However, some people >>> seemed to have an issue with that, so I was asked to "take it to the list". >>> >>> The main justification why a non-200 response would not cease the >>> re-transmission is because an intermediate may reject the PRACK, in >>> which case the UAS will never receive it (read: the UAS will continue >>> to re-transmit the reliable 18x). So, when the UAC receives the PRACK >>> non-200 response it should send a new PRACK, which hopefully will >>> reach the UAS and trigger a 200 response. >>> >>> So, anyone who does not agree with the justification aboive, and >>> thinks that a non-200 response DOES cease the re-transmission of the >>> associated reliable 18x response, please indicate so. >> >> I agree with Christer here. Another scenario where this would be >> important >> is: >> >> -> INVITE >> <- 180rel >> -> PRACK >> <- 401 >> >> It this case it is essential to retry the PRACK with updated credentials. >> Certainly the UAS doesn't want to consider the 180 to have been >> acknowledged in this case, since it might have been from a MiTM. >> >> This could come about in the case of a reINVITE, where the nonce used >> in the original INVITE finally becomes stale by the time the PRACK is received. >> >> Thanks, >> Paul >> _______________________________________________ >> 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 > _______________________________________________ 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
