> >> 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 response to a PRACK. The PRACK has > >> served its purpose. > > > > The UAC is unaware if the PRACK has served its purpose > > since it doesn't know if rejected by middle box or the > > UAS performing the retries. > > That's not the UAC's problem. It is if the UAC would like successfully deliver a PRACK. > The only reason a PRACK has a response is because you > had to fit it into one of the state machines defined in > RFC3261. It was to remain backward compatible to the RFC2543 concerning proxy interactions. Proxies (and other middle boxes) compliant with RFC3261 (or RFC2543) can return failure responses such as 407, 500, 503, 415, 420, and 488. > That doesn't mean we go a over analyze its response. The analyses is no more complex than typical in dialog response beyond recognition that the call might fail if the UAC does try a little harder to successfully deliver the PRACK. If a failure is received, the UAC needs to decide if it can and/or should resubmit the request with higher cseq (or fork request per rfc3263 upon 503). > > Similarly the UAC doesn't know if the UAS allowed the PRACK > > to be fully processed if a non-481 failure response (such as > > 401, 500, 503, 415, 420, and 488) was returned. > > What's fully processed? 1) Stopped 18x retries. 2) Considers 18x with offer (or answer) SDP successfully delivered to avoid queuing subsequent INVITE 18x, INVITE 2xx, and etcetera. 3) Honored PRACK delivered content adjustments per whatever the specifications allow. _______________________________________________ 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
