Received DTMF tones was not played for OPUS 48kHz

RESOLVED WONTFIX

Status

()

P4
normal
Rank:
35
RESOLVED WONTFIX
2 years ago
7 months ago

People

(Reporter: aries.nah, Unassigned)

Tracking

53 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce:

There is a Freeswitch server that commutates 2 webrtc clients (one of them is using Firefox), this Freeswitch sends offer containing opus 48kHz as audio codec, and telephone-event 48kHz since tones should use the same frequency as main audio stream, but list of supported codecs in Firefox contains telephone-event on 8kHz frequency only, thus Firefox replies with answer having no telephone-event and then it rejects all RTP packets having type 101.
I believe this is the reason why Firefox doesn't play beeps when caller on remote side clicks buttons on dialpad (aka sends DTMF tones).



INVITE sip:6jp4dfu3@vt3c6ofca7qs.invalid;transport=ws SIP/2.0
Via: SIP/2.0/WSS 10.27.29.12:7443;branch=z9hG4bK5acpg2mcy1rvK
Route: <sip:6jp4dfu3@10.11.132.56:49715>;transport=wss
Max-Forwards: 70
From: "P94" <sip:P94@10.27.29.12>;tag=gDQBS4vSFZ8eD
To: <sip:6jp4dfu3@vt3c6ofca7qs.invalid;transport=ws>
Call-ID: 4c5312d1-3b55-4071-8f4e-0580ff3e6a62
CSeq: 107091270 INVITE
Contact: <sip:mod_sofia@10.27.29.12:5060>
User-Agent: CC
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, essage-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 999
X-Bleg-Codec: G729
X-FS-Support: update_display,send_info
Remote-Party-ID: "P94" <sip:P94@10.27.29.12>;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1494836231 1494836232 IN IP4 10.27.29.12
s=FreeSWITCH
c=IN IP4 10.27.29.12
t=0 0
a=msid-semantic: WMS yZRgvzQHzMx9Nq0k0IIYidCkf6FPYUPm
m=audio 18438 RTP/SAVPF 102 101
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=8000; ptime=20; minptime=10; maxptime=40
a=rtpmap:101 telephone-event/48000
a=fingerprint:sha-256 2F:C8:26:D6:11:F4:4D:E1:2D:52:63:D2:92:A4:CA:73:38:E0:A5:FF:FD:03:81:74:E7:11:F2:F3:0C:5D:BB:B0
a=setup:actpass
a=rtcp-mux
a=rtcp:18438 IN IP4 10.27.29.12
a=ssrc:1243927949 cname:Kxt5W9DmM1lphbA8
a=ssrc:1243927949 msid:yZRgvzQHzMx9Nq0k0IIYidCkf6FPYUPm a0
a=ssrc:1243927949 mslabel:yZRgvzQHzMx9Nq0k0IIYidCkf6FPYUPm
a=ssrc:1243927949 label:yZRgvzQHzMx9Nq0k0IIYidCkf6FPYUPma0
a=ice-ufrag:K9WTdp3ilyXajDnT
a=ice-pwd:0HPNHjZjaazic0gNZ3w2ipbu
a=candidate:7635736256 1 udp 659136 10.27.29.12 18438 typ host generation 0
a=candidate:7635736256 2 udp 659136 10.27.29.12 18438 typ host generation 0
a=ptime:20




SIP/2.0 200 OK
Via: SIP/2.0/WSS 10.27.29.12:7443;branch=z9hG4bK5acpg2mcy1rvK
To: <sip:6jp4dfu3@vt3c6ofca7qs.invalid;transport=ws>;tag=4p4qjdn8jk
From: "P94" <sip:P94@10.27.29.12>;tag=gDQBS4vSFZ8eD
Call-ID: 4c5312d1-3b55-4071-8f4e-0580ff3e6a62
CSeq: 107091270 INVITE
Contact: <sip:6jp4dfu3@vt3c6ofca7qs.invalid;transport=ws>
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: outbound
User-Agent: Five9 Softphone SIP.js 0.7.7
Content-Type: application/sdp
Content-Length: 839

v=0
o=mozilla...THIS_IS_SDPARTA-53.0.2 3489672878140770511 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 2C:7C:76:37:A6:5D:FA:D3:1E:A5:66:6D:7A:51:36:AC:84:15:C4:E8:52:0C:E7:FE:06:09:A4:F5:C5:C0:6B:80
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 21561 UDP/TLS/RTP/SAVPF 102
c=IN IP4 149.62.27.45
a=candidate:0 1 UDP 2122252543 10.11.132.56 56348 typ host
a=candidate:1 1 UDP 1686052863 149.62.27.45 21561 typ srflx raddr 10.11.132.56 rport 56348
a=sendrecv
a=end-of-candidates
a=fmtp:102 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=ice-pwd:29380a4aa87738050b25322138f67648
a=ice-ufrag:84285368
a=msid:{f1eac303-d8b0-4431-aac0-eab5008806ab} {5250a062-9008-416d-9d89-a5f75f752bea}
a=rtcp-mux
a=rtpmap:102 opus/48000/2
a=setup:active
a=ssrc:15122579 cname:{d284c74c-786e-44f5-b4df-2a7f0c188806}



Actual results:

user that is using Firefox is not able to hear when remote caller sends dtmf tones


Expected results:

Firefox should play tones to current audio device as Chrome does
(Reporter)

Updated

2 years ago
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
(Reporter)

Updated

2 years ago
Component: Untriaged → WebRTC
Product: Firefox → Core

Comment 1

2 years ago
We only implemented sending DTMF tones in Firefox as we did not see a use case for being able to receive tones in the browser. If you could tell us more about what your plans are for receiving DTMF in Firefox, that would help us prioritize fixing this bug. Thanks!
Status: UNCONFIRMED → NEW
Rank: 35
Ever confirmed: true
Flags: needinfo?(aries.nah)
Priority: -- → P3
(Reporter)

Comment 2

2 years ago
We're writing software for Call Centers, few years ago we had to fix pretty similar issue but with native softphone application.
The use case was the following:

There is some company with 24/7 support phone number and configured IVR, but a client can't go over this IVR.
So, he calls to support phone and complainы that something wrong with their IVR.
The support creates a conference call with the client and IVR, and asks the client to repeat his actions.
And in this case, the agent would like to hear if some dtmf tones are really sent by client.
Flags: needinfo?(aries.nah)
Aren't you at that point testing more if Freeswitch generating DTMF towards the browser works (plus Freeswitch recognizing the DTMF from the client)?


Adam what do you think about adding support for receiving/listening to DTMF?
Flags: needinfo?(adam)

Comment 4

2 years ago
Yeah, I think this is a wontfix.

In general, supporting decoding of DTMF in the browser has extremely limited utility, and I don't think it's a feature we want to spend resources implementing, testing, and maintaining.

In this specific case, using Opus from a Freeswitch where the other end is a PSTN call is a vast waste of resources (both bandwidth and CPU). The Freeswitch should be configured to use G.711 towards the browser and turn off telephone-event.
Flags: needinfo?(adam)
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4

Comment 6

7 months ago
Marking this as wontfix as per comment 4.
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.