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

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