WebRtc: Chrome should support Asymmetric payload types in re-invite.
Reported by
rajsripe...@gmail.com,
Jul 1 2016
|
|||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Steps to reproduce the problem: WebRTC doesn’t support asymmetric payload types for 2 codecs DTMF and WideBand Comfort Noise (CN) in the re-invite.ie it doesn’t allow MP to use different numbers for these two payload types. This happens only on re-invite. The following diagram illustrates this problem. Consider X and Y are the payload types used by WebRTC and A and B as the payload types used by NonWebRTC client. WebRTC NonWebRTC ================================================ Offer----DTMF PT=X, Wideband CN PT=Y---------> <--------DTMF PT=A, Wideband CN PT=B------Answer <--------DTMF PT=A, Wideband CN PT=B------Reinvite Chrome rejects the Re-invite as it doesn't like a different payload type then what it used. Strangely it doesn't reject the answer for the same reason. What is the expected behavior? Chrome accepts the payload types which are different than its own. What went wrong? Call is dropped. Did this work before? No Chrome version: 51.0.2704.103 Channel: canary OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0
,
Jul 11 2016
[triage] Blum, looks like a product question. Can you take a look? Leaving as bug for now (not sure if it's a feature request).
,
Jul 12 2016
From a conceptional point of view I don't understand why Chrome rejects the re-invite. The standards perspective might be different.
,
Aug 1 2016
Standards perspective: The inconsistency (accepting the answer and not accepting the re-invite) is wrong, if this is the only difference between them. Can you attach printouts of the SDP in the offer, answer and re-invite, as well as the precise error that Chrome emits when asked to accept the re-invite? These should be available from Chrome's webrtc-internals page.
,
Aug 9 2016
[triage] rajsripeddi@ could you do the steps suggested in #4? Thanks!
,
Sep 9 2016
[triage] rajsripeddi@: ping regarding the requested feedback.
,
Oct 3 2016
Closing in lack of feedback.
,
Oct 5 2016
Bernard, can you provide the requested SDP traces?
,
Oct 6 2016
,
Oct 21 2016
Calling setLocalDescription on the original caller fails with: DOMException: Failed to set local answer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set local audio description recv parameters.. The following fiddle reproduces the issue: https://jsfiddle.net/gn4wyk9z/4/
,
Oct 27 2016
Thanks for the wonderfully short reproduction script!
,
Oct 27 2016
When runnign the fiddle, the stderr log in tip-of-tree Chrome says: [1:14:1027/103806:ERROR:webrtcvoiceengine.cc(1750)] telephone-event payload type changed. [1:13:1027/103806:ERROR:channel.cc(850)] Failure in SetLocalContent with action 2 [1:13:1027/103806:ERROR:webrtcsession.cc(332)] Failed to set local answer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set local audio description recv parameters..
,
Mar 10 2017
,
Mar 10 2017
,
Mar 12 2017
,
Mar 13 2017
Fredrik - can you take a look and see if we should handle it or if failing is the right thing?
,
Mar 13 2017
This is a SDP negotiation thing, and we should handle it.
,
Mar 13 2017
I just tested and wasn't able to reproduce this. rajsripeddi@, can you see if it's working for you now? If not, could you attach the SDP?
,
Apr 3 2018
Closing since I wasn't able to reproduce. |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by kavvaru@chromium.org
, Jul 5 2016Labels: Te-NeedsFurtherTriage