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? 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
