Re: PRACK: Does non-200 response cease re-transmission of reliable 18x?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux