setLocalDescription fails when previous BUNDLE-tag m= section is rejected in subsequent offer
Reported by
ushunmu...@gmail.com,
May 12 2017
|
|||||||||
Issue description
What steps will reproduce the problem?
1. Establish an audio + video call between a Chrome WebRTC client and a peer.
2. Have the peer send a new offer with the audio m-line disabled (port set to 0), say, for downgrading it to a video-only call. The offer should still contain "a=group:BUNDLE video" following RFC 5888.
3. Do setRemoteDescription in Chrome client with the remoteSDP, create the answer SDP, and then do setLocalDescription with the answer.
What is the expected result?
setLocalDescription succeeds.
What do you see instead?
setLocalDescription fails with the following error: "Failed to push down transport description: Applying an answer transport description without applying any offer".
What version of the product are you using? On what operating system?
Version 58.0.3029.96 (64-bit) - on Windows 10 Enterprise
Please provide any additional information below.
The offer to downgrade to video-only looks like this:
...
a=group:BUNDLE video
a=msid-semantic: WMS 8125B60C-2E2F-4E86-A34C-49C23AC6D9BC
m=audio 0 RTP/SAVPF 0
m=video 36001 RTP/SAVPF 96
...
a=mid:video
...
The answer generated by Chrome looks like this:
...
a=group:BUNDLE video
a=msid-semantic: WMS lFfzLGmvkwNrM4CVhnTvWMH7opHOj1WKSoyC
m=audio 0 RTP/SAVPF 0
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=mid:audio
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ssrc:3250779170 cname:MFt1g9taool4VPgZ
a=ssrc:3250779170 msid:lFfzLGmvkwNrM4CVhnTvWMH7opHOj1WKSoyC 6425a00f-1b45-4e18-820c-9c9df812326a
a=ssrc:3250779170 mslabel:lFfzLGmvkwNrM4CVhnTvWMH7opHOj1WKSoyC
a=ssrc:3250779170 label:6425a00f-1b45-4e18-820c-9c9df812326a
m=video 61490 RTP/SAVPF 96
...
a=mid:video
...
,
May 12 2017
The same issue is exhibited in Canary - Version 60.0.3097.0 (Official Build) canary (64-bit).
,
May 15 2017
,
May 15 2017
,
May 16 2017
,
May 16 2017
,
May 18 2017
With media bundle, when audio gets disabled, Chrome cannot seem to handle the video stream (I guess ICE should be redone here). The error message still doesn't make sense to me. See the attached file with the chrome debug log.
,
May 23 2017
,
Jun 20 2017
Ping for triage.
,
Jul 11 2017
Sorry for the delay, but yes, this is a known issue. A more general statement of the issue is that we don't support rejecting the "bundle transport" m= section in a subsequent offer. The way we implement bundling is by having transports identified by MIDs. So pre-bundling, things look like: VoiceChannel -> "audio" transport VideoChannel -> "video" transport Then when an answer is applied, the VideoChannel starts pointing at the "audio" transport, because "audio" is the first thing in "a=group": VoiceChannel -> "audio" transport VideoChannel / Finally, when an offer that rejects the "audio" section is applied, the "audio" transport is destroyed. Then when the answer is applied, things start pointing to the nonexistent "video" transport instead. Which is why you get the un-intuitive "Applying an answer transport description without applying any offer" message. To fix this, we need some logic that says "this BUNDLE group in the re-offer is the same group as the previous answer, even though the BUNDLE-tag changed", and do something smarter than simply identifying transports by name. Rejecting the "audio" section shouldn't destroy the "audio" transport, because it's not just the audio transport any more; it's the BUNDLE group transport.
,
Jul 11
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 12
Still an issue.
,
Jul 12
Bumping to P3. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by ushunmu...@gmail.com
, May 12 2017