w3c / webrtc-pc Goto Github PK

See JSEP section 4.1.1. Need to be able to set (balanced, max-compat, max-bundle, max-bundel-and-rtcpmux )

Originally reported on W3C Bugzilla ISSUE-25957 Tue, 03 Jun 2014 10:03:39 GMT
Reported by Harald Alvestrand
Assigned to

At the May 20 meeting of WEBRTC, it was agreed that errors on a PeerConnection that aren't associated with a specific object or function need to be reported through an "error" event on the PeerConnection itself.

The exemplar event was a failure in TURN server authentication; another is the perennial "internal error".

This needs to be added to the WebRTC spec.

Originally reported on W3C Bugzilla ISSUE-21880 Tue, 30 Apr 2013 18:14:58 GMT
Reported by Martin Thomson
Assigned to

The current specification is silent on how peer certificates are managed.

Current implementations appear to mint a new certificate for every new connection. This is good from a privacy perspective because it ensures that no two sessions can be linked based solely on certificate contents. Of course that assumes that the certificate doesn't contain a DN that contains linkable information.

Volatile certificates create a minor performance issue (certificate generation is fast, but it's not that fast) and a major traceability issue. If there is no stability in certificates, then you lose the ability to audit sessions. It's not possible to determine if the peer you were talking to is really the person you expected - they are probably unable to produce the certificate that they used during the session because the certificate has since been destroyed.

This leads to a need for some degree of persistence, with certain constraints:

1. Certificates cannot be the same across different origins, i.e., your identity must be unlinkable across origins.
2. It must be possible to use a different certificate when talking to different people on the same site, i.e., your identity must be unlinkable across peers.
3. Certificates need to be destroyed when cookies are destroyed, i.e., you must be able to control linkability over time.

Requirement 2 is the most interesting case because this implies that there needs to be some interaction with the application to achieve this, not just the browser. Only the application has any hope of having prior knowledge of identity such that this would be possible.

Note: A DTLS peer acting in the server role presents their certificate without any prior knowledge of the identity of the peer, and a client presents their certificate without actually verifying the server identity.

This implies that there needs to be some control surface to allow applications to control certificate options. This needs to be separate to the existing peer identity constraints because these privacy protections are needed in the absence of identity assertions. In fact, anonymity cases are where these are most needed.

Originally reported on W3C Bugzilla ISSUE-25440 Thu, 24 Apr 2014 11:28:42 GMT
Reported by Kiran
Assigned to

In WebRTC spec [1] in section 9.2.2 Events on MediaStream,
the ready state attribute has been initialized to muted.

But MediaStreamTrack readyState [2] does not contain "muted" state. It contains only new, live and ended states.

enum MediaStreamTrackState {
"new",
"live",
"ended"
};

Since "muted" state is also considered as "live" state [3], perhaps it may be initialized to "live" instead of muted.

or

It should be initialized with "live" if the connection is established (which is the source for a remote stream) otherwise with "live".

[1] http://dev.w3.org/2011/webrtc/editor/webrtc.html#events-on-mediastream
[2] http://www.w3.org/TR/mediacapture-streams/#idl-def-MediaStreamTrackState
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22259

Originally reported on W3C Bugzilla ISSUE-22441 Tue, 25 Jun 2013 01:37:02 GMT
Reported by Gang Liang
Assigned to

The 4th bullet of section 8.1.2 Requesting Assertions, it mentions "The IdP sends a "SIGN" message (Section 5.6.5.2.2) to the IdP proxy context. " It is not correnct. It should be that the RTCPeerConnection sends a "SIGN" message rather than Idp.

Originally reported on W3C Bugzilla ISSUE-25834 Tue, 20 May 2014 20:15:37 GMT
Reported by Cullen Jennings
Assigned to

Originally reported on W3C Bugzilla ISSUE-25533 Fri, 02 May 2014 08:44:18 GMT
Reported by Kiran
Assigned to

Considering the following use-case

An offerer creates and offer, set it in browser through setLocalDescription. The signaling state transits from stable to have-local-offer. Now application cancels this offer before receiving the answer from remote peer.

In this scenario, spec should specify that the browser state should be rolled-back to previous stable state.

Originally reported on W3C Bugzilla ISSUE-25828 Tue, 20 May 2014 15:26:27 GMT
Reported by Cullen Jennings
Assigned to

Originally reported on W3C Bugzilla ISSUE-23920 Tue, 26 Nov 2013 08:35:06 GMT
Reported by Harald Alvestrand
Assigned to

When TURN credentials fail to validate, the fact should be reported to the Javascript through some interface.

Ideally, this interface should be usable for other types of errors too.

In 4.3.2.3 [1], there is a paragraph:

If the candidate parameter is malformed, throw a SyntaxError exception and abort these steps.

malformed shall mean 'not conforming to a standard type'. For example, if the candidate parameter is an empty string "", addIceCandidate shall throw a TypeError exception rather than a SyntaxError per the WebIDL dictionary definition [2]. At least the spec [1] is not clear on this aspect.

[1] http://w3c.github.io/webrtc-pc/#widl-RTCPeerConnection-addIceCandidate-void-RTCIceCandidate-candidate-VoidFunction-successCallback-RTCPeerConnectionErrorCallback-failureCallback
[2] http://heycam.github.io/webidl/#es-dictionary

Originally reported on W3C Bugzilla ISSUE-26279 Tue, 08 Jul 2014 03:36:44 GMT
Reported by Kiran
Assigned to

Options attribute is missing for createAnswer [1].
As per RFC 3264 section 6.1 [2], Answerer should have provision to respond with the preferred option.

1. recvonly or inactive if the offered stream is sendonly.

2. sendonly or inactive if the offered stream is recvonly.

3. sendrecv or recvonly or sendonly or inactive if the offered stream is sendrecv.

   "If a stream is offered as sendonly, the corresponding stream MUST be
   marked as recvonly or inactive in the answer. If a media stream is
   listed as recvonly in the offer, the answer MUST be marked as
   sendonly or inactive in the answer. If an offered media stream is
   listed as sendrecv (or if there is no direction attribute at the
   media or session level, in which case the stream is sendrecv by
   default), the corresponding stream in the answer MAY be marked as
   sendonly, recvonly, sendrecv, or inactive. If an offered media
   stream is listed as inactive, it MUST be marked as inactive in the
   answer"

[1] http://dev.w3.org/2011/webrtc/editor/webrtc.html#interface-definition
[2] http://tools.ietf.org/html/rfc3264#page-9

Originally reported on W3C Bugzilla ISSUE-25828 Tue, 20 May 2014 15:26:27 GMT
Reported by Cullen Jennings
Assigned to

Originally reported on W3C Bugzilla ISSUE-23920 Tue, 26 Nov 2013 08:35:06 GMT
Reported by Harald Alvestrand
Assigned to

When TURN credentials fail to validate, the fact should be reported to the Javascript through some interface.

Ideally, this interface should be usable for other types of errors too.

Originally reported on W3C Bugzilla ISSUE-21877 Tue, 30 Apr 2013 17:04:45 GMT
Reported by Martin Thomson
Assigned to

The ability to handle inbound media prior to an answer arriving is a key reason that the WebRTC API uses SDP offer/answer. However, this presents several challenges.

1. ICE: the offerer is expected to nominate pairs, but it cannot send connectivity checks prior to learning about the answerer's ufrag and password. Since the offerer is responsible for nominating, nothing happens until the answer arrives.

2a. Security Descriptions: the offerer doesn't know about the decryption keys for newly arrived streams.
2b. DTLS: the offerer can complete the handshake, but cannot render media until it obtains an identity assertion.

3a. Media: the offerer cannot correlate an inbound packet with an m= line by SSRC (if packet types are unique, then this could be used).
3b. The offerer does not know how to identify the inbound media stream and what grouping it fits within (CNAME, if present, is unsuitable because CNAME can be the same for multiple MediaStreams).

This has been discussed at some length in the IETF. It could be that the IETF arrive at some sort of conclusion on how to address this within SDP. I consider that unlikely (as unlikely as any statement of the form "... IETF arrive at some sort of conclusion ... SDP"). There are also discussions in the IETF around providing labeling on the media path.

It may be that some of these can't be addressed easily, or the situation changes depending on what multiplexing is in place, for example. Certainly, less of these factors are a problem when a new stream is added to a multiplexed bundle on an existing transport (only 3a, 3b and maybe 2a apply).

Regardless of what the IETF concludes it's likely that there will be a need for API changes to support this feature (3b in particular).

CU-RTC-Web addresses this problem by providing an event for an as-yet-unsignaled media flow. This event indicates SSRC and packet type of the unknown packet. It also requests that browsers buffer this inbound stream for a short time. Buffering would probably just include enough time to allow the application to process and respond to the event, there is no need to allow enough time to perform any signaling, which would undermine the whole "real time" aspect of this and potentially cause buffering space to be larger than is tolerable.

The CU-RTC-Web solution is fairly simple because it pushes responsibility onto the application. That might be an undesirable property, though it might be argued that this is an advanced usage of the API and the extra application responsibility is commensurate with that.

An alternative solution involves the creation of "dummy" media streams that exist for a short time. There are several variations on this. In one solution the streams that are created are single track streams with undefined identifiers. Another alternative suggests that a single default stream is created with all unannounced tracks attached to it.

There is another alternative to be considered for 3b, which is that identifiers could be allocated locally (CU-RTC-Web does this). In order to correlate streams with the ones on the remote peer a new attribute, remoteid, is added to include the identifier used by the source. The 'remoteid' would only be populated once signaling arrived.

'remoteid' provides a measure of stability that the "dummy" stream configurations cannot provide. 'remoteid' would probably supplant the recently added 'remote' attribute.

Originally reported on W3C Bugzilla ISSUE-21877 Tue, 30 Apr 2013 17:04:45 GMT
Reported by Martin Thomson
Assigned to

The ability to handle inbound media prior to an answer arriving is a key reason that the WebRTC API uses SDP offer/answer. However, this presents several challenges.

1. ICE: the offerer is expected to nominate pairs, but it cannot send connectivity checks prior to learning about the answerer's ufrag and password. Since the offerer is responsible for nominating, nothing happens until the answer arrives.

2a. Security Descriptions: the offerer doesn't know about the decryption keys for newly arrived streams.
2b. DTLS: the offerer can complete the handshake, but cannot render media until it obtains an identity assertion.

3a. Media: the offerer cannot correlate an inbound packet with an m= line by SSRC (if packet types are unique, then this could be used).
3b. The offerer does not know how to identify the inbound media stream and what grouping it fits within (CNAME, if present, is unsuitable because CNAME can be the same for multiple MediaStreams).

This has been discussed at some length in the IETF. It could be that the IETF arrive at some sort of conclusion on how to address this within SDP. I consider that unlikely (as unlikely as any statement of the form "... IETF arrive at some sort of conclusion ... SDP"). There are also discussions in the IETF around providing labeling on the media path.

It may be that some of these can't be addressed easily, or the situation changes depending on what multiplexing is in place, for example. Certainly, less of these factors are a problem when a new stream is added to a multiplexed bundle on an existing transport (only 3a, 3b and maybe 2a apply).

Regardless of what the IETF concludes it's likely that there will be a need for API changes to support this feature (3b in particular).

CU-RTC-Web addresses this problem by providing an event for an as-yet-unsignaled media flow. This event indicates SSRC and packet type of the unknown packet. It also requests that browsers buffer this inbound stream for a short time. Buffering would probably just include enough time to allow the application to process and respond to the event, there is no need to allow enough time to perform any signaling, which would undermine the whole "real time" aspect of this and potentially cause buffering space to be larger than is tolerable.

The CU-RTC-Web solution is fairly simple because it pushes responsibility onto the application. That might be an undesirable property, though it might be argued that this is an advanced usage of the API and the extra application responsibility is commensurate with that.

An alternative solution involves the creation of "dummy" media streams that exist for a short time. There are several variations on this. In one solution the streams that are created are single track streams with undefined identifiers. Another alternative suggests that a single default stream is created with all unannounced tracks attached to it.

There is another alternative to be considered for 3b, which is that identifiers could be allocated locally (CU-RTC-Web does this). In order to correlate streams with the ones on the remote peer a new attribute, remoteid, is added to include the identifier used by the source. The 'remoteid' would only be populated once signaling arrived.

'remoteid' provides a measure of stability that the "dummy" stream configurations cannot provide. 'remoteid' would probably supplant the recently added 'remote' attribute.

Originally reported on W3C Bugzilla ISSUE-27225 Mon, 03 Nov 2014 20:37:39 GMT
Reported by Harald Alvestrand
Assigned to

Reference presentation: https://www.w3.org/2011/04/webrtc/wiki/images/6/6c/WebRTC_RTCSender-Receiver%2C_TPAC_2014.pdf slide 11

This was received favorably by the group, and solves some problems including placing a track on "mute" and limiting its bandwidth. A fleshed-out proposal needs to be presented to the WG for adoption.

Originally reported on W3C Bugzilla ISSUE-25835 Tue, 20 May 2014 20:15:58 GMT
Reported by Cullen Jennings
Assigned to

This issue serves as an alert to the watchers of this repository; on Monday December 15, I'll be importing 116 issues from the W3C Bugzilla instance to the github issues of this repository, which will trigger a significant number of email notifications.

There is unfortunately no way that I know of of disabling these notifications; if you don't want these notifications, you should unwatch the repository between Monday 00am and 12pm UTC.

See jsep section 4.1.1.

In 4.2.1.1 the spec reads:

iceServers of type sequence<RTCIceServer>
An array containing URIs of servers available to be used by ICE, such as STUN and TURN server.

which doesn't specify that it may be "null" as well. At least that's what Chrome seems to allow me to do just fine. So I'm wondering if it's just me being too easily surprised here, the spec being a tad fuzzy or the implementation being off...

Sorry if this is a silly question :/

Originally reported on W3C Bugzilla ISSUE-25834 Tue, 20 May 2014 20:15:37 GMT
Reported by Cullen Jennings
Assigned to

See info in
https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-17#section-12.2.1

Originally reported on W3C Bugzilla ISSUE-25513 Wed, 30 Apr 2014 07:12:28 GMT
Reported by Kiran
Assigned to

As discussed in Bug 25361 [1], WebRTC spec should explicitly specify all the muted events of a MediaStramTrack related to RTCPeerConnection

1. Tracks sourced from m-mline and marked as RecvOnly in SDP should be considered muted tracks.
2. Muted state resulted due to doohickey actions.

// May be some more other events related to PeerConnection.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25361

Originally reported on W3C Bugzilla ISSUE-25513 Wed, 30 Apr 2014 07:12:28 GMT
Reported by Kiran
Assigned to

As discussed in Bug 25361 [1], WebRTC spec should explicitly specify all the muted events of a MediaStramTrack related to RTCPeerConnection

1. Tracks sourced from m-mline and marked as RecvOnly in SDP should be considered muted tracks.
2. Muted state resulted due to doohickey actions.

// May be some more other events related to PeerConnection.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25361

Originally reported on W3C Bugzilla ISSUE-22442 Tue, 25 Jun 2013 01:44:10 GMT
Reported by Gang Liang
Assigned to

The 4th bullet of section 8.1.3 Verifying Assertions, it mentions "The IdP sends a "VERIFY" message (Section 5.6.5.2.2) to the IdP proxy context." It is not correnct. It should be that the RTCPeerConnection sends a "VERIFY" message rather than Idp.

In #29, @stefhak noted that we don't really specify how we handle inbound media that isn't yet assigned to a MediaStreamTrack through signaling. This can happen with renegotiation+bundling at the offerer. We don't specify whether to keep the data, or what to do with it.

I tend to think that this falls into the space where you have resource and quality trade-offs that aren't really very safe to specify for the general case. A machine with lots of RAM can store several jitter buffers worth of audio and several I-frames, but there are limits to how much they can store. There are also limits too on processing capacity to handle all that media properly.

In the same way we don't specify jitter buffer size and depth, I'm going to recommend closing this issue without at most some editorial additions.

Originally reported on W3C Bugzilla ISSUE-21880 Tue, 30 Apr 2013 18:14:58 GMT
Reported by Martin Thomson
Assigned to

The current specification is silent on how peer certificates are managed.

Current implementations appear to mint a new certificate for every new connection. This is good from a privacy perspective because it ensures that no two sessions can be linked based solely on certificate contents. Of course that assumes that the certificate doesn't contain a DN that contains linkable information.

Volatile certificates create a minor performance issue (certificate generation is fast, but it's not that fast) and a major traceability issue. If there is no stability in certificates, then you lose the ability to audit sessions. It's not possible to determine if the peer you were talking to is really the person you expected - they are probably unable to produce the certificate that they used during the session because the certificate has since been destroyed.

This leads to a need for some degree of persistence, with certain constraints:

1. Certificates cannot be the same across different origins, i.e., your identity must be unlinkable across origins.
2. It must be possible to use a different certificate when talking to different people on the same site, i.e., your identity must be unlinkable across peers.
3. Certificates need to be destroyed when cookies are destroyed, i.e., you must be able to control linkability over time.

Requirement 2 is the most interesting case because this implies that there needs to be some interaction with the application to achieve this, not just the browser. Only the application has any hope of having prior knowledge of identity such that this would be possible.

Note: A DTLS peer acting in the server role presents their certificate without any prior knowledge of the identity of the peer, and a client presents their certificate without actually verifying the server identity.

This implies that there needs to be some control surface to allow applications to control certificate options. This needs to be separate to the existing peer identity constraints because these privacy protections are needed in the absence of identity assertions. In fact, anonymity cases are where these are most needed.

Originally reported on W3C Bugzilla ISSUE-27224 Mon, 03 Nov 2014 20:33:59 GMT
Reported by Harald Alvestrand
Assigned to

Reference presentation:

https://www.w3.org/2011/04/webrtc/wiki/images/6/6c/WebRTC_RTCSender-Receiver%2C_TPAC_2014.pdf slide 9

This has been presented to the WG, and won support, but needs to be reviewed in detail before integrating.

Originally reported on W3C Bugzilla ISSUE-27224 Mon, 03 Nov 2014 20:33:59 GMT
Reported by Harald Alvestrand
Assigned to

Reference presentation:

https://www.w3.org/2011/04/webrtc/wiki/images/6/6c/WebRTC_RTCSender-Receiver%2C_TPAC_2014.pdf slide 9

This has been presented to the WG, and won support, but needs to be reviewed in detail before integrating.

Originally reported on W3C Bugzilla ISSUE-20816 Tue, 29 Jan 2013 18:17:46 GMT
Reported by Matthew Kaufman
Assigned to

The WebRTC draft and its normative references do not define a mechanism for applications for placing a session on hold. Similarly, no mechanism is defined for receivers to use in requesting that a sender stop the transmission of a specific stream for the purposes of muting that stream.

Originally reported on W3C Bugzilla ISSUE-25957 Tue, 03 Jun 2014 10:03:39 GMT
Reported by Harald Alvestrand
Assigned to

At the May 20 meeting of WEBRTC, it was agreed that errors on a PeerConnection that aren't associated with a specific object or function need to be reported through an "error" event on the PeerConnection itself.

The exemplar event was a failure in TURN server authentication; another is the perennial "internal error".

This needs to be added to the WebRTC spec.

Originally reported on W3C Bugzilla ISSUE-22442 Tue, 25 Jun 2013 01:44:10 GMT
Reported by Gang Liang
Assigned to

The 4th bullet of section 8.1.3 Verifying Assertions, it mentions "The IdP sends a "VERIFY" message (Section 5.6.5.2.2) to the IdP proxy context." It is not correnct. It should be that the RTCPeerConnection sends a "VERIFY" message rather than Idp.

Originally reported on W3C Bugzilla ISSUE-27225 Mon, 03 Nov 2014 20:37:39 GMT
Reported by Harald Alvestrand
Assigned to

Reference presentation: https://www.w3.org/2011/04/webrtc/wiki/images/6/6c/WebRTC_RTCSender-Receiver%2C_TPAC_2014.pdf slide 11

This was received favorably by the group, and solves some problems including placing a track on "mute" and limiting its bandwidth. A fleshed-out proposal needs to be presented to the WG for adoption.

Originally reported on W3C Bugzilla ISSUE-25440 Thu, 24 Apr 2014 11:28:42 GMT
Reported by Kiran
Assigned to

In WebRTC spec [1] in section 9.2.2 Events on MediaStream,
the ready state attribute has been initialized to muted.

But MediaStreamTrack readyState [2] does not contain "muted" state. It contains only new, live and ended states.

enum MediaStreamTrackState {
"new",
"live",
"ended"
};

Since "muted" state is also considered as "live" state [3], perhaps it may be initialized to "live" instead of muted.

or

It should be initialized with "live" if the connection is established (which is the source for a remote stream) otherwise with "live".

[1] http://dev.w3.org/2011/webrtc/editor/webrtc.html#events-on-mediastream
[2] http://www.w3.org/TR/mediacapture-streams/#idl-def-MediaStreamTrackState
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22259

Originally reported on W3C Bugzilla ISSUE-25596 Thu, 08 May 2014 06:00:44 GMT
Reported by Harald Alvestrand
Assigned to

After discussion on the list (May 2014), it seems agreed that:

• updateIce is a bad name for the function, since it updates more than ICE
• it makes sense to just give a single call that updates the configuration given to the RTCPeerCOnnection constructor
• setConfiguration() is a good name for this function
• we also need getConfiguration() to provide the ability to modify a configuration parameter

This seems ready for editing.

Originally reported on W3C Bugzilla ISSUE-27226 Mon, 03 Nov 2014 23:14:20 GMT
Reported by Harald Alvestrand
Assigned to

Suggested API: Slide 14 of

https://www.w3.org/2011/04/webrtc/wiki/images/6/6c/WebRTC_RTCSender-Receiver%2C_TPAC_2014.pdf

This needs some more work to sort out relationships with SDP codec descriptions and other places where codec capabilities are presented.

Originally reported on W3C Bugzilla ISSUE-23919 Tue, 26 Nov 2013 08:22:10 GMT
Reported by Harald Alvestrand
Assigned to

At the moment, the type of event fired at the onerror interface is a TODO.

Suggestion: Define an Error event that contains the same data as a DOMError (a name and a message).

Originally reported on W3C Bugzilla ISSUE-25596 Thu, 08 May 2014 06:00:44 GMT
Reported by Harald Alvestrand
Assigned to

After discussion on the list (May 2014), it seems agreed that:

• updateIce is a bad name for the function, since it updates more than ICE
• it makes sense to just give a single call that updates the configuration given to the RTCPeerCOnnection constructor
• setConfiguration() is a good name for this function
• we also need getConfiguration() to provide the ability to modify a configuration parameter

This seems ready for editing.

(see section 3.4.4. of JSEP)

Sometimes it's capitalized, other times not.

Originally reported on W3C Bugzilla ISSUE-22441 Tue, 25 Jun 2013 01:37:02 GMT
Reported by Gang Liang
Assigned to

The 4th bullet of section 8.1.2 Requesting Assertions, it mentions "The IdP sends a "SIGN" message (Section 5.6.5.2.2) to the IdP proxy context. " It is not correnct. It should be that the RTCPeerConnection sends a "SIGN" message rather than Idp.

Originally reported on W3C Bugzilla ISSUE-26279 Tue, 08 Jul 2014 03:36:44 GMT
Reported by Kiran
Assigned to

Options attribute is missing for createAnswer [1].
As per RFC 3264 section 6.1 [2], Answerer should have provision to respond with the preferred option.

1. recvonly or inactive if the offered stream is sendonly.

2. sendonly or inactive if the offered stream is recvonly.

3. sendrecv or recvonly or sendonly or inactive if the offered stream is sendrecv.

   "If a stream is offered as sendonly, the corresponding stream MUST be
   marked as recvonly or inactive in the answer. If a media stream is
   listed as recvonly in the offer, the answer MUST be marked as
   sendonly or inactive in the answer. If an offered media stream is
   listed as sendrecv (or if there is no direction attribute at the
   media or session level, in which case the stream is sendrecv by
   default), the corresponding stream in the answer MAY be marked as
   sendonly, recvonly, sendrecv, or inactive. If an offered media
   stream is listed as inactive, it MUST be marked as inactive in the
   answer"

[1] http://dev.w3.org/2011/webrtc/editor/webrtc.html#interface-definition
[2] http://tools.ietf.org/html/rfc3264#page-9

Originally reported on W3C Bugzilla ISSUE-25533 Fri, 02 May 2014 08:44:18 GMT
Reported by Kiran
Assigned to

Considering the following use-case

An offerer creates and offer, set it in browser through setLocalDescription. The signaling state transits from stable to have-local-offer. Now application cancels this offer before receiving the answer from remote peer.

In this scenario, spec should specify that the browser state should be rolled-back to previous stable state.

Originally reported on W3C Bugzilla ISSUE-25856 Wed, 21 May 2014 18:51:31 GMT
Reported by Cullen Jennings
Assigned to

Perhaps this needs to go in gum

Originally reported on W3C Bugzilla ISSUE-20816 Tue, 29 Jan 2013 18:17:46 GMT
Reported by Matthew Kaufman
Assigned to

The WebRTC draft and its normative references do not define a mechanism for applications for placing a session on hold. Similarly, no mechanism is defined for receivers to use in requesting that a sender stop the transmission of a specific stream for the purposes of muting that stream.

Originally reported on W3C Bugzilla ISSUE-23919 Tue, 26 Nov 2013 08:22:10 GMT
Reported by Harald Alvestrand
Assigned to

At the moment, the type of event fired at the onerror interface is a TODO.

Suggestion: Define an Error event that contains the same data as a DOMError (a name and a message).

Originally reported on W3C Bugzilla ISSUE-27226 Mon, 03 Nov 2014 23:14:20 GMT
Reported by Harald Alvestrand
Assigned to

Suggested API: Slide 14 of

https://www.w3.org/2011/04/webrtc/wiki/images/6/6c/WebRTC_RTCSender-Receiver%2C_TPAC_2014.pdf

This needs some more work to sort out relationships with SDP codec descriptions and other places where codec capabilities are presented.

See section 4 of rtp-usage