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. > >Yeah, that's not the issue. That IS the issue. If it wasn't, I think most people would agree that the re-transmission is ceased - at least nobody has said otherwise in the previous e-mail discussions we've had on this. >Of course the UAS will retransmit in this case. It hasnt seen the PRACK. The issue is if the >UAS does receive the PRACK but rejects it. > >In my opinion, unless the UAS responds with a 401, the PRACK has served its purpose. I agree with you, and the way 3262 is written is more or less says that the re-transmission of the 18x stops when the PRACK is received - before you know what the final response is going to be. But, again, the problem with that solution is that the UAC cannot be sure whether the UAS actually received the PRACK, and therefor the proposed solution is that it sends a new PRACK in case of a non-200 response. Regards, Christer > >>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
