Solved DTMF issue in v18

[George Ts]

Hello,

Following this thread https://www.3cx.com/community/threa...hones-use-rfc2833-provider-uses-inband.80787/ we have upgraded our 3cx (Enterprise Annual license) to v18 (Build 1880).
Our SIP provider is Vodafone (Greece) and they only accept DTMF as inband.
I have set up a Fanvil X4U IP phone to use DTMF inband, and placed a call to PSTN (Vodafone) from that IP Phone.
So the call flow is:
Fanvil X4U - - > 3cx V18 - - > Vodafone (SIP)

I took a Wireshark trace, debugged the RTP and noticed the following:
Fanvil sends DTMF as inband to 3cx
3cx sends DTMF as RFC2833 to Vodafone

Since Vodafone only supports inband, the outgoing DTMF fails.

Why has 3cx detected the Vodafone SIP Trunk to be using RFC2833?

If this helps, the same IP phone (Fanvil X4U) is also used to open the office's door phone, Fanvil i20S. That door phone only accepts RFC2833. The IP Phone is sending inbad to 3cx, and 3cx is sending RFC2833 to the door phone. So, this scenario (opening the door with DTMF #1) works. But we are having issue with all DTMF digits sent to PSTN.

Thank you,
George

 

[JohnS_3CX]

Why has 3cx detected the Vodafone SIP Trunk to be using RFC2833?

Hi George,

This is above is the important part so I will address it directly before we talk about the Fanvils.

Check the 200 OK that Vodaphone sent you when the other side answered.
Inside the SDP part, did it contain something called a telephone-event?


Note: I'm assuming the capture was made on the PBX - inform me if this is otherwise

 

[George Ts]

Good point @JohnS_3CX
Indeed, their 200OK includes the following line:

rtpmap:101 telephone-event/8000

Which means that Vodafone actually supports RFC2833 based on their 200OK response...

 

[JohnS_3CX]

Yes.. so unfortunately if they advertise it in the SDP, then the PBX will send it.

The way we detect it in V18 is that if the other side does not include a telephone-event, we must assume in band and act accordingly.

The problem here is that they claim they support RFC2833, but when we send it they ignore it.
Unfortunately this is a built in function in 3CX, so you cannot force it to always convert to in band.

Can you ask them to remove it by any chance?

 

[George Ts]

The strangest thing is that for another extension, provisioned on 3cx for Windows, the issue does not persist. Vodafone keeps sending the telephone-event but the DTMF is inband end to end and it works. Any idea why this may happen? In the meantime, we contacted Vodafone and will post updates here.
UPDATE: Vodafone has applied all 3 different settings on their SIP trunk (inband, rfc2833 and auto), none of which works. I am afraid we are stuck here. It would be great if - instead of doing this automatically - we were allowed to configure the DTMF mode per SIP trunk, like most asterisk-based PBXs do (Elastix included)

 

[JohnS_3CX]

That could be because the 3CX client is set to in band manually

By the way you mentioned Vodafone PSTN earlier and I was wondering how your lines are setup:

- is it an IP based trunk over the internet?
- is it using a hardware device that converts SIP to PSTN lines going into the wall (FXO gateway)?

 

[George Ts]

Hi @JohnS_3CX
I abused the word "PSTN".
This is just an IP based SIP trunk between our 3cx and Vodafone's SIP-enabled equipment (Oxygen CPE).
No POTS or ISDN to SIP converter included.

 

[George Ts]

And to answer your previous comment, indeed, the 3cx for Windows client is configured to use inband DTMF. But so does the Fanvil IP phone. Also, since the call flow is:
3cx client --> 3cx PBX --> Vodafone
and since Vodafone includes the "telephone-event" in their 200OK response, I would expect this call to behave identically as the Fanvil to Vodafone call, i.e. 3cx converting the inband DTMF (in the call leg between extension and 3cx) to RFC2833 (in the call leg between 3cx and Vodafone).
However, what I noticed in the 3cx client case, is that the 3cx server is sending DTMF inband to Vodafone, despite the "telephone-event" in Vodafone's 200OK. I would be curious to understand why this happens. Thank you

 

[JohnS_3CX]

Ah nevermind, I thought it might have been an FXO gateway. In that case we could have disabled RFC2833 manually without involving the provider.

As for the V16 Windows client, please ignore it's behavior, it was not updated to work 1:1 with the new V18 media server so it is not a good example to use in this case.

 

[George Ts]

Thank you @JohnS_3CX
So, to sum up:
- Vodafone cannot do anything to stop the "telephone-event" in their 200OK response's SDP, even if their equipment is configured to use inband DTMF. Unfortunately, this has been confirmed in action.
- Our IP Phones are having issues with outbound DTMFs to Vodafone, but our 3cx clients work just fine at the moment. However, this is just temporary and quite probably will change when 3cx clients get upgraded to the new v18 version, at which point 3cx clients' DTMFs will also stop working.
I see no way out here, other than falling back to v16, if we absolutely need to fix the DTMFs in our environment.
Perhaps having Vodafone to install another CPE in our premise, which does not include the "telephone event" in the SDP when it is configured to use inband DTMF.
Is my understanding correct?

 

[NickD_3CX]

Your understanding is correct.

Although I doubt the issue is on the Vodafone CPE on your premise, so changing it probably won't make much difference.
Generally 3CX prefers RFC2833 DTMF tones, so if the providers state in their SIP messages that they support "telephone-event" that is what we'll use.

 

[George Ts]

Thanks for your confirmation Nick. Indeed, I am afraid that the telephone event is received by Vodafone's core network, and the CPE will not change much. However, this is our last resort at the moment, so we need to try.
In the meantime, like suggested above, it would be great if 3cx allowed the definition of a DTMF method on a SIP trunk level, just like Elastix did. Do you see the possibility of such a development (or in an ideal world - a hotfix) in the future, or would 3cx plan to stick to the Auto setting?
Just asking in order to know if it's worth suggesting this in the ideas section.

 

[NickD_3CX]

Do you see the possibility of such a development (or in an ideal world - a hotfix) of this feature in the future, or would 3cx plan to stick to the Auto setting?
Just asking in order to know if it's worth suggesting this in the ideas section.

Honestly, I don't see this changing.

 

[JohnS_3CX]

Hi George

We do have a couple of fully supported providers in Greece though, and this could rid you of the problem entirely.
If I were you I would look into them as options and compare them with what you are paying Vodafone now.

They may make you an offer you can't refuse
https://www.3cx.com/partners/sip-trunks/greece/

 

[George Ts]

Thank you both @JohnS_3CX and @NickD_3CX .
We already have a great cooperation with Modulus, but the number of calls to mobiles we make, does not allow us to use Modulus as our main provider.

Vodafone now reverted saying that their equipment sends the telephony-event in the SDP, just because 3cx sends it in its INVITE.

To me this sounds nonsense, as the UAS should not be affected by what the UAC suggests in the SDP.
The UAS sends its own supported list of media atrributes - regardless of what the UAC suggests - and at the end both the UAC and UAS use their common media attributes.

If I may ask, can you point me to an RFC reference confirming the above?
We need to put Vodafone's argument down at this point, and an RFC reference would be good for this scope.

Thank you,
George

 

[JohnS_3CX]

Hi George,

You don't want to enter an RFC quoting match.. It is not really the job of the customer to do so in the first place anyway, I would strongly advise against doing this.


Just for your own information, here is part of the intro from RFC3264

The offer is conveyed to the other participant, called the answerer. The answerer generates an answer, which is an SDP message that responds to the offer provided by the offerer. The answer has a matching media stream for each stream in the offer, indicating whether the stream is accepted or not, along with the codecs that will be used and the IP addresses and ports that the answerer wants to use to receive media.

In simple terms, if I offer something and you reply back including what I offered, it means you accept that offer (whether it is a codec or a telephone event).

Otherwise, you'd indicate that you do not accept it.

 

[George Ts]

Thank you very much for your support on this thread @JohnS_3CX and @NickD_3CX
Eventually Vodafone installed another CPE on our premise and they contacted the CPE vendor, who confirmed that there is a setting to not send the "telephone event" when inband is configured on the CPE.
As a result, our outbound DTMF now work fine, as 3cx uses DTMF inband for the respective SIP trunk.
Many thanks. Please feel free to close this thread.

George

 

[JohnS_3CX]

Hi George,

Happy to hear all is now sorted!