Issue metadata
Sign in to add a comment
|
Gets error: 'Failed to set remote video description send parameters' while trying to make a call with H264.
Reported by
jbustama...@broadsoft.com,
Jan 23 2017
|
||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Steps to reproduce the problem:
1. Make a call from custom WebRTC client to a web conference.
2. Conference responds with SDP having h264 profile-level-id=42800d
3. Gets error on console:
exsip.js:11 0113/161308 : ExSIP | RTCMediaHandler : onsignalingstatechange : stable
exsip.js:13 ----------setRemoteDescription with error : {}
exsip.js:11 0113/161308 : ExSIP | RTC SESSION : OperationError: Failed to set remote answer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set remote video description send parameters..
What is the expected behavior?
This should work and call should be established.
What went wrong?
Call is not established.
Did this work before? Yes Version 55.0.2883.87 (64-bit) stable
Does this work in other browsers? N/A
Chrome version: 56.0.2924.59 beta (64-bit) Channel: beta
OS Version: Mint 17.2
Flash Version: Shockwave Flash 24.0 r0
profile-level-id=42e01f or 42e01e works, but not 42800d.
Investigating issue, just found that corresponding call to WebRtcVideoChannel2::SelectSendVideoCodec(...) returns an empty VideoCodecSetting on failing case, while returning a valid VideoCodecSetting on working case (different profile-level-id)
,
Jan 24 2017
Tested in chrome stable #55.0.2883.87,Beta #56.0.2924.67 & Canary #58.0.2990.0 on Ubuntu 14.04 and not able to reproduce the issue.Please find the screen shots for your reference. @Wouters:Could you please let me know if i have missed anything and if possible, please check in latest versions and create new profile, recheck once and let us know the observations which would help us to triage the issue further. Thanks in Advance.
,
Jan 30 2017
@jbustamante: Could you please update on comment #2. Thank you!
,
Jan 30 2017
I am not sure why you are not able to reproduce, I would guess you are not setting the right profile-level-id that would reproduce it. I investigated further and found that this is caused by commit master@155a5b4f This is introduced on Chrome version 56.0.2918.0. Here is the review-url: https://codereview.webrtc.org/2483173002 Basically, browser compares profile-level-id against internal default Constrained Baseline profile, and if the remote profile (while setting remote description) is different, an error is thrown. Since remote end is returning 42800d (Baseline profile) on my case, error is encountered. I haven't gone through specs to say for sure if this can be really treated like an error or if this is just the way it is supposed to work (or if it is just a kind of accepted work-around).
,
Feb 7 2017
Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 9 2017
,
Feb 9 2017
This is expected behavior, Chromium only supports Constrained Baseline profile for H264, and not (unconstrained) Baseline profile. I think openh264 actually supports more profiles, so then it would be possible to add support for more H264 profiles in chrome, but I don't think it's very high priority work. Can you use Constrained Baseline profile for now? You can still lower the H264 level, i.e. you can use 42e00d.
,
Mar 2 2017
@ jbustamante : Could you please update on comment#7. Thank you!
,
Mar 10 2017
Changing from unconfirmed to available per comment #7.
,
Mar 10 2017
I am sorry, I thought I posted a reply some days ago but somehow I can't see my comment, so I guess it got lost. I wrote that I have made changes on our WebRTC Gateway to always send Constrained Baseline profile on SDPs to browser and I don't get the issue anymore, so I can confirm the proposed solution on comment #7 (for now, at least) works fine.
,
Mar 13 2017
Thanks for checking and reporting back. Closing this issue for now as working-as-intended. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by jbustama...@broadsoft.com
, Jan 23 2017