PJSIP – Dtmf Mode Is Not Updated When The Far End Doesn’t Support Rfc2833
Hello, I have installed the latest version 12 that has been released (12.1.0.rc3).
I have setup default dtmf mode (rfc47..) but when I am calling to a endpoint that doesn’t support it (no telephony event in the rtpmap) the asterisk responds OK in the signalling but DTMF is not working.
Is it a known issue?
Below you can see the output of the asterisk monitor.
<--- Received SIP request (1182 bytes) from UDP:10.25.153.150:5060 --->
INVITE sip:039988120@172.16.60.160:5060;user=phone SIP/2.0
Record-Route:
Via: SIP/2.0/UDP 10.25.153.150:5060;branch=z9hG4bK587.67258295.0
Via: SIP/2.0/UDP
10.1.1.10;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.qLOBF6zGZLMBj7MBvuMx3AMB1jmxuqC93X3heroEWvH9vsCFN43qdAMxyAMxyAMxyAMlMZMxpJ3lqwWxarW.gqWReJMEPA36juW6WBzR363RVA3Ejugx3*
Max-Forwards: 68
From: “39937841 39937841”
To:
Call-ID: 2915b6e4-02e3a8c0-0000be53@192.168.225.2
CSeq: 2 INVITE
Contact:
User-Agent: NetCentrex CCS Softswitch/7.16.0
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, INFO, PRACK, UPDATE, NOTIFY
Supported: 100rel P-Asserted-Identity: “39937841 39937841”
Min-SE: 90
Privacy: none Content-Type: application/sdp Content-Length: 167
v=0
o.206.22.171 62708 2 IN IP4 10.206.22.171
s=SIP Call c=IN IP4 10.206.22.171
t=0 0
a=sendrecv m=audio 41040 RTP/AVP 8
a=rtpmap:8 PCMA/8000/1
a=ptime:20
<--- Transmitting SIP response (602 bytes) to UDP:10.25.153.150:5060 --->
SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.25.153.150:5060
;rport;received.25.153.150;branch=z9hG4bK587.67258295.0
Via: SIP/2.0/UDP
10.1.1.10;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.qLOBF6zGZLMBj7MBvuMx3AMB1jmxuqC93X3heroEWvH9vsCFN43qdAMxyAMxyAMxyAMlMZMxpJ3lqwWxarW.gqWReJMEPA36juW6WBzR363RVA3Ejugx3*
Record-Route:
Call-ID: 2915b6e4-02e3a8c0-0000be53@192.168.225.2
From: “39937841 39937841”
To:
CSeq: 2 INVITE
Content-Length: 0
— Executing [039988120@from-external:1] NoOp(“PJSIP/sipp-00000000″, ”
H E L L O ! ! !”) in new stack
— Executing [039988120@from-external:2]
DumpChan(“PJSIP/sipp-00000000”, “”) in new stack
Dumping Info For Channel: PJSIP/sipp-00000000:
===============================================================================Info:
Name= PJSIP/sipp-00000000
Type= PJSIP
UniqueID= 172.16.60.160-1394542052.0
LinkedID= 172.16.60.160-1394542052.0
CallerIDNum= 39937841;cpc=payphone CallerIDName= 39937841 39937841
ConnectedLineIDNum= (N/A)
ConnectedLineIDName=(N/A)
DNIDDigits= (N/A)
RDNIS= (N/A)
ParkinglotLanguage= en State= Ring (4)
Rings= 1
NativeFormat= (alaw)
WriteFormat= alaw ReadFormat= alaw RawWriteFormat= alaw RawReadFormat= alaw WriteTranscode= No ReadTranscode= No
1stFileDescriptor= -1
Framesin= 0
Framesout= 0
TimetoHangup= 0
ElapsedTime= 0h0m0s BridgeID= (Not bridged)
Context= from-external Extension= 039988120
Priority= 2
CallGroupPickupGroupApplication= DumpChan Data= (Empty)
Blocking_in= (Not Blocking)
Variables:
=============================================================================== — Executing [039988120@from-external:3] Answer(“PJSIP/sipp-00000000”,
“”) in new stack
<--- Transmitting SIP response (1060 bytes) to UDP:10.25.153.150:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.25.153.150:5060
;rport;received.25.153.150;branch=z9hG4bK587.67258295.0
Via: SIP/2.0/UDP
10.1.1.10;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.qLOBF6zGZLMBj7MBvuMx3AMB1jmxuqC93X3heroEWvH9vsCFN43qdAMxyAMxyAMxyAMlMZMxpJ3lqwWxarW.gqWReJMEPA36juW6WBzR363RVA3Ejugx3*
Record-Route:
Call-ID: 2915b6e4-02e3a8c0-0000be53@192.168.225.2
From: “39937841 39937841”
To:
4 thoughts on - PJSIP – Dtmf Mode Is Not Updated When The Far End Doesn’t Support Rfc2833
I don’t think that’s an issue at all.
Your configured your endpoint to support RFC 4733 DTMF. However, the INVITE request that was received by Asterisk didn’t offer support for DTMF, so Asterisk can’t accept it. It has to accept only what is in the offer.
Your configuration can’t force the UA to offer what it wants – you can only configure Asterisk with what it should support with that UA.
There’s really only two possible outcomes here:
(1) Reject the INVITE request with a 488 (you didn’t offer me DTMF!)
(2) Accept the INVITE request but not have DTMF over RFC 4733.
What you’re seeing is option (2), which I think is better than rejecting the entire call simply because the thing you are talking to doesn’t support the DTMF mode you configured it to have.
Hi Mathew, The regular sip stack has ‘auto’ dtmfmode which behaved as I said – if the remote replied with telephony event it used RFC2833 otherwise it used inband.
Correct. There is no setting for dtmf_mode that is analogous to the chan_sip ‘auto’ setting – what you configure for you endpoint today is what it will use.
That’s not a bug, just something not existing yet.
Matt
Mathew, Thanks Mathew. It’s good to know the limitations 🙂
Is there any plan to add it?