Well, since we technically allow it to carry SDP and pretty much anything, then a while series of 4xx could be triggered related to body handling issues I guess. Technically it's supposed to be used like an ACK I think, so "carefully". But even just with SDP it may, in theory, be too big to reach the UAS. Or if a pidf-location body is added, for example. It can also carry a Require/Proxy-Require header and be rejected due to that, not that I can think of why that would realistically ever be an issue for PRACK. -hadriel > -----Original Message----- > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf > Of Hisham Khartabil > Sent: Wednesday, April 01, 2009 10:15 PM > To: Rockson Li (zhengyli) > Cc: Paul Kyzivat (pkyzivat); sipping@xxxxxxxx; Christer Holmberg > Subject: Re: PRACK: Does non-200 response cease re-transmission > ofreliable 18x? > > 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 _______________________________________________ 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
