New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 775408 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

rtcpMuxPolicy update breack FRC 5671

Reported by ovoshl...@gmail.com, Oct 17 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce the problem:
1. Make call  with SDP description that contains 
a=rtcp:<port value> different than at the 
a=media <port value>
a=rtcp-mux
a=candidate:EcscmRJBKCo12Xws 1 UDP 2130706431 1.2.3.4 <rtp port value> typ host
a=candidate:EcscmRJBKCo12Xws 2 UDP 2130706430 1.2.3.4  <rtcp port value> typ host

What is the expected behavior?
Accept call an start session

What went wrong?
Session will be dropped

Did this work before? Yes 61.0.3163.100

Does this work in other browsers? Yes

Chrome version: 63.0.3237.0  Channel: stable
OS Version: 10.0
Flash Version: 

I suppose it is crosses with #685727 bug in the root of the trouble

suppose code ignores description in RFC 5761 (says that a=rtcp:<port> can provide different port with media for legacy endpoints even if a=rtcp-mux added at the media description) and drops session if offer has a different ports at the m=audio and a=rtcp:  but has a=rtcp-mux a the session.

At hte attached file example of the behaivor at the IP notation
 
RFC 5761 ignoring.txt
2.4 KB View Download

Comment 1 by guidou@chromium.org, Oct 18 2017

Components: -Blink>WebRTC Blink>WebRTC>Network

Comment 2 by ovoshl...@gmail.com, Oct 18 2017

Found that if i set 
a=rtcp:<port> same with 
m=audio <port> issue still exists

Suppose problem with 
a=rtcp:<port> param If it exsists - chromium breaks session.

Aslo notice that all fine in chrome 62.
Cc: sc00335...@techmahindra.com
Labels: -Pri-2 M-64 Needs-Triage-M63 Pri-1
Owner: deadbeef@chromium.org
Status: Assigned (was: Unconfirmed)
As per comment#0 assigning to @deadbeef. 

@deadbeef: Please confirm the bug and help in re-assigning if it is not related to your change.
Status: WontFix (was: Assigned)
This SDP is actually failing to be applied due to the presence of both "a=fingerprint" and "a=crypto". In the native log, there's a slightly cryptic (no pun intended) error message that alludes to this: "Cryptos must be empty when DTLS is active."

This was a change we made intentionally in M63. See: https://groups.google.com/d/msg/discuss-webrtc/_aePBY7Ga4E/a6qljdbXBQAJ

Would it be feasible to just remove the "a=crypto" lines when applying the SDP on the Chrome side?

Comment 5 by ovoshl...@gmail.com, Oct 22 2017

Yep .fixed it on serevr side. thx for answer
issue can be closed

Sign in to add a comment