FreePhoneLine.ca SIP to PJSIP - No INbound DTMF decoding anymore

Asterisk Asterisk SIP
1

Hello there,

Upgraded from Asterisk 16 to 22 so had to forget SIP and use PJSIP instead.

INcoming DTMF (i.e. people calling me and sending DTMF to access IVR options) is not recognized anymore.

Recorded incoming call plays the tones sent by the caller.

Previous functioning dialplan included this line “same => n,SIPDtmfMode(rfc2833)” but this does not work with PJSIP.

I did not see any kind of DTMF type negotiation within the SIP trace.

Tried all available options from
https://docs.asterisk.org/Latest_API/API_Documentation/Module_Configuration/res_pjsip/#dtmf_mode
in the trunk registration but to no avail.

Outgoing DTMF on the other hand is working okay.

Thanks in advance for your suggestions.

2

You need to actual provide a SIP trace using “pjsip set logger on”, an RTP trace using “rtp set debug on”, and the configuration.

3

PJSIP trace : Asterisk PJSIP trace - Pastebin.com

4

RTP trace : Asterisk RTP trace - Pastebin.com

5

pjsip_wizard.conf excerpt :

[fplca5144471234]
type = wizard
sends_auth = yes
sends_registrations = yes
remote_hosts = voip.freephoneline.ca:5060
registration/max_retries = 99999
registration/retry_interval=120
outbound_auth/username = 15144471234
outbound_auth/password = RedactedPassword
endpoint/allow = ulaw
endpoint/context = inbound
endpoint/contact_user=15144471234
;-----------------------------------------------------------------------
endpoint/fax_detect=yes

6

It is indeed not offering DTMF over RTP, and there currently is no ability in PJSIP to override the SDP negotiated result for DTMF and force it. I don’t see a way for it to work with RFC4733 without code additions.

7

On Monday 13 October 2025 at 13:41:21, jcolp via Asterisk Community wrote:

It is indeed not offering DTMF over RTP, and there currently is no ability
in PJSIP to override the SDP negotiated result for DTMF and force it. I
don’t see a way for it to work with RFC4733 without code additions.

Indeed - PJSIP does not support DTMF over RTP.

I would recommend investigating whether this PortsSIP thing can be told to do
RFC2833.

Antony.

–
Douglas was one of those writers who honourably failed to get anywhere with
‘weekending’. It put a premium on people who could write things that lasted
thirty seconds, and Douglas was incapable of writing a single sentence that
lasted less than thirty seconds.

  • Geoffrey Perkins, about Douglas Adams
8

Thank you both for this information.
I understand that chan_PJSIP does not support DTMF over RTP but chan_sip did?

9

The chan_pjsip module supports DTMF over RTP, when negotiated in SDP which it is supposed to be. No negotiation is happening (they aren’t offering it) so it does not work. The SIPDtmfMode application from chan_sip, from what I can tell, ignored the negotiation and switched it on. I’m not sure if that resulted in it going back in our answer to them (which I’m pretty sure would violate the RFC) or not.

10

On Monday 13 October 2025 at 15:48:46, jcolp via Asterisk Community wrote:

The chan_pjsip module supports DTMF over RTP, when negotiated in SDP which
it is supposed to be.

Oh. Am I mis-reading this, then?

"PJSUA2 and PJSUA-LIB support sending DTMF digits as inband tone, RTP events
(RFC 4733/RFC 2833), or SIP INFO.

On the receiving side, the libraries support reporting DTMF digits sent as RTP
events (RFC 4733/RFC 2833) and SIP INFO.

Note that detection of inband DTMF tone is currently not implemented."

Antony.

–
Procrastination: working tomorrow for a better today.

11

Asterisk doesn’t use the PJSIP media stack at all, so what it supports doesn’t matter to Asterisk itself. The same media stack used by chan_sip is used by chan_pjsip.

12

On Monday 13 October 2025 at 16:23:30, jcolp via Asterisk Community wrote:

Asterisk doesn’t use the PJSIP media stack at all, so what it supports
doesn’t matter to Asterisk itself. The same media stack used by chan_sip
is used by chan_pjsip.

Oh, this is more complicated than I thought :slight_smile:

Thanks.

Antony.

–
When you find yourself arguing with an idiot,
you should first of all make sure
that the other person isn’t doing the same thing.

13

So, just to make sure I got that right :
Unless an addition is made to PJSIP to set DTMF mode recognition regardless of the SDP negotiation result value, my options would be to:

  • Get the provider to update its negotiation scheme.
  • Find another provider which does it right.
  • Downgrade Asterisk to version 20 (latest version supporting chan_sip)

Is that correct?
Thanks again.

14

Yes.

15

I should add, unless DTMF is actually being received just as inband DTMF - then you could set DTMF mode to inband but that’s not something that is negotiated in SIP/SDP, so I can’t say if it is.

16

Reverted to v20 with chan_sip and expected behaviour has returned.
Do you think PJSIP will ever implement the required application (e.g. PJSIPDtmfMode(rfc2833)) ?
Thanks for your time.

17

It’s not on the radar of the Asterisk team at Sangoma, but I can’t speak for anyone else. Asterisk is an open source project, so if someone puts a change up for review then we’ll consider it.