1xx. The retransmitting of PRACK will of course cease when the respone (whatever the response code is) is received. When I talk about "UAC sending a new PRACK" I don't mean re-transmit the previous PRACK. I am talking about generating a PRACK, which hopefully is less likely to be rejected. -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@xxxxxxxxx] Sent: Thursday, April 02, 2009 7:07 AM To: Christer Holmberg Cc: Hadriel Kaplan; Rockson Li (zhengyli); Paul Kyzivat (pkyzivat); sipping@xxxxxxxx Subject: Re: PRACK: Does non-200 response cease re-transmission ofreliable 18x? Are you talking about retransmitting of PRACK or 1xx? 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. > > 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
