Hi, >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? Well, rejecting an SDP offer is one use-case we've discussed. The PRACK could also be rejected due to some overload situation etc. Regards, Christer 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
