2009/4/2 Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>: > > 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. 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. Hisham > >>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
