- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 07 May 2014 22:55:40 +0200
- To: public-webrtc@w3.org
On 05/07/2014 06:19 PM, Paul Kyzivat wrote: > On 5/7/14 5:46 AM, Kiran Kumar Guduru wrote: >> Hi, > >> [KIRAN] In PRACK case, If the SIP user agent is not willing to accept an >> offer, if it responds with an error response, than that terminates that >> particular SIP Invite / Re-Invite transaction. >> >> In such case, it will roll-back to the state that is negotiated by >> previous Invite- with final ANSWER. >> >> This case has been outlined (it has not explained in brief) in RFC 6337, >> section 2.3 Table-2. >> >> Offer Rejection >> ------------------------------------------------------------------ >> 1. INVITE Req. (*) 488 INVITE Response >> 2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer >> OR termination of dialog >> 3. INVITE Req. 488 INVITE Response (same as Pattern 1) >> 4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer >> 5. PRACK Req. (**) 200 PRACK Resp. followed by new offer >> OR termination of dialog >> 6. UPDATE Req. 488 UPDATE Response >> >> [1] http://tools.ietf.org/html/rfc6337#page-5 > > Note that the OR in row 5 above was added because we felt we had do > say something about that case in RFC 6337. > > RFC 3262 says: > > If the PRACK does match an > unacknowledged reliable provisional response, it MUST be responded to > with a 2xx response. > > It is saying the PRACK *MUST* succeed. Unfortunately it ignored the > reality that it might not be possible to accept the PRACK. (For > instance, the message might not be well formed, or it may be that > security credentials are incorrect, etc.) > > So in 6337 we acknowledged that it might be necessary to fail it, and > then specified what should happen next to make the best of the bad > situation. And the best here is to give up on the whole session. There > aren't any rollback provisions in this case, and we didn't feel it was > appropriate for 6337 to define any. So in PeerConnection terms, you either apply the answer in a 200 PRACK response or you discard the PeerConnection entirely? If so, the problem identified by Kiran doesn't seem to be a big problem; we can certainly do that without any new transitions in the state diagram. > > The bottom line of this is that one should be very careful about > putting offers in PRACKs. If you are doing so you had better limit > yourself to offers that are virtually certain to be accepted by an > entity that accepted the previous offer. > > Thanks, > Paul >
Received on Wednesday, 7 May 2014 20:56:10 UTC