2009/4/2 Hadriel Kaplan <HKaplan@xxxxxxxxxxxxxx>: > > 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. If the 1xx carried and answer, then the PRACK would carry an offer. Rejecting that offer in the PRACK with a 4xx by the UAS should not impact the assertion that the 1xx has reached its destination. Therefore no point in retransmitting the 1xx. If the 1xx carried the offer, then the PRACK would carry the answer, in which case the UAS cannot reject, but can issue a new offer or tear down the call. Again, no point in retransmitting the 1xx. The 1xx has been achnowledged to be received. > > 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. Again, we need to look at what the PRACK is really doing. It is acknowledging that the 1xx has reached its destination. Hisham > > -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
