Open Bug 1414807 Opened 7 years ago Updated 2 years ago

RTCPeerConnection: Remote description changes

Categories

(Core :: WebRTC: Audio/Video, defect, P3)

56 Branch
defect

Tracking

()

People

(Reporter: mparisdiaz, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171003101344

Steps to reproduce:

Just run the next JSFiddle script: https://jsfiddle.net/91mu5f2d/17/


Actual results:

When a remote offer reuses a m-line changing the media type the next error is thrown:
"Remote description changes the media type of m-line 1"


Expected results:

The offer should be accepted as it follows https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-5.2.2
Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core
I can confirm the results of the jsfiddle, but I'm not sure how to prioritize this. Nils, what do you think?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(drno)
Let's have a look at this after transceivers are landed, because I fear they change our behavior as well as the expected behavior in this area.
Rank: 25
Depends on: 1290948
Flags: needinfo?(drno)
Priority: -- → P3
OK
Could you please ping here when you expect to have this fixed?
Transceivers landed and the fiddle still produces the error. Byron what do you think about this one in terms of prioritizing?
Flags: needinfo?(docfaraday)
I suppose we could allow this, but I do not think it is a good idea for us to create an offer that does this; it will not interop with anything besides other browsers.
Flags: needinfo?(docfaraday)
Also, you are not allowed to change the type of an m-section unless it was rejected (port 0) during the last negotiation, which does not appear to be the case in that fiddle.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.