Modifying the state by re-applying the last PRANSWER transition as an ANSWER will result in ambiguity.


Consider the following error scenario, where UAC and UAS are two peers, sender and receiver respectively.


1.       A call is established between UAC and UAS, and both are in STABLE state.

2.       Now UAC initiated negotiation with OFFER in a SIP Re-Invite, received PRANSWER in 183 session progress.

3.       UAC transits its state to HAVE-LOCAL-OFFER and that of UAS to HAVE-REMOTE-OFFER.

4.       UAS sends the PRANSWER and transits to HAVE-LOCAL-PRANSWER and that of UAC to HAVE-REMOTE-PRANSWER. (It is fine till this point).

5.       For sending offer in PRACK, if UAC re-applies the PRANSWER as final ANSWER then, UAC transits to STABLE state and UAS transits to HAVE-REMOTE-OFFER.

6.       If the UAS want to reject the OFFER in PRACK and roll-back, then it will roll-back to previous STABLE state. But the STABLE state of UAC is not the expected STABLE state 


And so finally ends up in ambiguous state.

Same might be the case for establishing a new session as well.


------- Original Message -------

Sender : Harald Alvestrand<>

Date : May 07, 2014 13:36 (GMT+09:00)

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


On 05/06/2014 04:05 PM, wrote:
>             Bug ID: 25579
>            Summary: State transitions are missing in RTCPeerConnections
>                     state transition diagram.
>            Product: WebRTC Working Group
>            Version: unspecified
>           Hardware: All
>                 OS: All
>             Status: NEW
>           Severity: normal
>           Priority: P2
>          Component: WebRTC API
>           Assignee:
>           Reporter:
>                 CC:
> Created attachment 1472
>   -->
> The attachment gives the updated state transition diagram for
> RTCPeerConnection.
> RTCPeerConnection's state transition diagram, specified in spec [1], is missing
> to indicate following state transitions state transitions.
> 1. have-remote-pranswer to have-local-offer
> 2. Have-local-pranswer to have-remtoe-offer

Those two transitions are intended to be impossible. If you want to go
from have-pranswer to have-offer, you need to go via the idle state.

> The same is applicable for statemachine defined in section 3.2 of JSEP draft
> [2].
> This state transitions are MUST to support section 5 of RFC 3262 [3] prack
> case.
> "If the UAC receives a reliable provisional response with an answer, it MAY
> generate an additional offer in the PRACK."

You can achieve the effect by re-applying the last PRANSWER transition
as an ANSWER.

People who understand PRACK can comment further.

> Please find the attachment for the proposed state transition diagram, which
> includes these state.
> [1]
> [2]
> [3]

Surveillance is pervasive. Go Dark.