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

On 05/07/2014 09:28 AM, Kiran Kumar Guduru wrote:
> Samsung Enterprise Portal mySingle
>
> 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.
>

This is illogical. UAC would re-apply the PRANSWER as final ANSWER and 
then apply its new offer, resulting in being in HAVE-LOCAL-OFFER state. 
It can't be in STABLE state while it has an outstanding offer.
(if I've understood the description correctly. I don't know PRACK details.)

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

What would the expected STABLE state be in a PRACK (non-WebRTC 
implementation?
That is - after rejecting the OFFER in PRACK, would the UAS expect the 
UAC to be in the state of having accepted the previous offer, or in the 
state of not having accepted any offer?

> 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<harald@alvestrand.no>
>
> *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, bugzilla@jessica.w3.org wrote:
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25579
> >
> >             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: public-webrtc@w3.org
> >           Reporter: kiran.guduru@samsung.com
> >                 CC: public-webrtc@w3.org
> >
> > Created attachment 1472
> >   --> https://www.w3.org/Bugs/Public/attachment.cgi?id=1472&action=edit
> > 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] http://dev.w3.org/2011/webrtc/editor/webrtc.html#state-definitions
> >
> > [2] http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#page-7
> >
> > [3] http://www.ietf.org/rfc/rfc3262.txt
> >
>
>
> -- 
> Surveillance is pervasive. Go Dark.
>
>