Hi, >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. True. But the UAC doesn't know whether the UAS, or some intermediate, rejected the offer. >Again, we need to look at what the PRACK is really doing. It is acknowledging that the 1xx has reached its destination. As Hadriel said: I wish that was all it was doing. Regards, Christer >> -----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
