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

Sender : Harald Alvestrand<harald@alvestrand.no>

Date : May 07, 2014 19:33 (GMT+09:00)

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

 

On 05/07/2014 11:46 AM, Kiran Kumar Guduru wrote:

Hi,

My apologies, I missed one point.

Please find my comments inline.

 

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

Sender : Harald Alvestrand<harald@alvestrand.no>

Date : May 07, 2014 17:46 (GMT+09:00)

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

 

On 05/07/2014 09:28 AM, Kiran Kumar Guduru wrote:

 

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

[KIRAN] The following step is missing

                    5.1.  After sending the offer in PRAC, UAC transits to HAVE-LOCAL-OFFER and that of UAS continues to be in HAVE-REMOTE-OFFER. (As specified by you)

Now after this if you check the setp 6,

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


I don't think I read your text properly, possibly because each line contains multiple things. Let me try to rephrase....

1. The call is in STABLE state, a connection is established. Let's call this "Stable state 0".
2. UAC creates a SIP INVITE, and installs the OFFER inside it. UAC is now in HAVE-LOCAL-OFFER.
3. UAC sends the SIP INVITE to UAS.
4. UAS receives the SIP INVITE, installs the OFFER. It is now in HAVE-REMOTE-OFFER.
5. UAS generates an ANSWER, packages it inside a 183 session progress message, and installs it locally as a PR-ANSWER. It is now in HAVE-LOCAL-PRANSWER state.
6. UAS sends the 183 Session Progress message to UAC.
7. UAC receives the 183 Session Progress message, installs the ANSWER inside of it as a PR-ANSWER, and is now in HAVE-REMOTE-PRANSWER state. (Are we agreed that we have now finished step 4 in the original description?)
8. UAC generates a PRACK request with an OFFER inside of it.
9. UAC installs the generated OFFER on top of the HAVE-REMOTE-PRANSWER state.

Turns out my head started hurting at step 8. Which state is the new OFFER described as a change from? "Stable state 0" or the stable state corresponding to what the state would be after HAVE-REMOTE-PRANSWER was applied as a final answer?

Now, if we start over from step 8:

8. UAC decides it wants to generate a new OFFER, and therefore installs the ANSWER from 183 as a final ANSWER. It is now in STABLE. Let's call this "Stable state 1".
9. UAC generates a PRACK request with an OFFER inside of it, and installs the OFFer. It is now in HAVE-LOCAL-OFFER.
10. UAC sends PRACK to UAS.
11. UAS gets the PRACK and decides to reject it. It is still in HAVE-LOCAL-PRANSWER state.
12. UAS decides the dialog is over, and installs the PRANSWER as final answer. It is now in "Stable State 1".
13. UAC gets the rejection message, and calls Rollback. It is now in "Stable State 1".

This seems self-consistent, but it might not be what people using PRACK expect.

What do people using PRACK expect?


[KIRAN] From my understanding after reading RFC 3262 and 6337, people using PRACK can handle it in two ways,

 

1. The first way is to send 200 OK with modified ANSWER (in correct acceptable format) for the OFFER in PRACK, without rejecting with error response and sending a new OFFER (200 PRACK Resp. followed by new offer).

     This new OFFER will be sent by UAS in 200 OK for INVITE and UAC sends the ANSWER in ACK for INVITE.

     This case is possible with existing state transitions.

 

2. The second way is to reject the Invite dialog, which includes rejecting OFFER in PRACK as well as INVITE (termination of dialog). i.e., to transit to STABLE state, "stable state 0".

    If we follow the steps from setp-8, 9,... and if the UAS is implemented to behave like that in second way, then UAS will transits to STABLE state, "stable state 0", and that of UAC to STABLE "stable state 1", which is the problematic case.


 

 

[KIRAN] UAC will transits to intermediate STABLE state and that of UAS will transits to its 1ts 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?

[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

 

 

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.