This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25579 - State transitions are missing in RTCPeerConnections state transition diagram.
Summary: State transitions are missing in RTCPeerConnections state transition diagram.
Status: RESOLVED WONTFIX
Alias: None
Product: WebRTC Working Group
Classification: Unclassified
Component: WebRTC API (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Web RTC Working Group
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-06 14:05 UTC by Kiran
Modified: 2014-10-31 16:57 UTC (History)
2 users (show)

See Also:


Attachments
The attachment gives the updated state transition diagram for RTCPeerConnection. (73.19 KB, application/pdf)
2014-05-06 14:05 UTC, Kiran
Details

Description Kiran 2014-05-06 14:05:28 UTC
Created attachment 1472 [details]
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

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

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
Comment 1 Harald Alvestrand 2014-10-31 16:57:48 UTC
WG agrees that such a transition should not be added.

If an application needs to support PRACK, it needs to drive the state machine through multiple transitions in order to get from have-remote-pranswer to have-local-offer, and deal with the necessary consequences.

The PeerConnection state machine is not a SIP state machine.