W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Re: [Bug 25579] New: State transitions are missing in RTCPeerConnections state transition diagram.

From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Date: Wed, 07 May 2014 12:19:35 -0400
Message-ID: <536A5D17.4080502@alum.mit.edu>
To: public-webrtc@w3.org
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.

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 16:20:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:40 UTC