Yaron Nachum
2014-Mar-11 13:23 UTC
[asterisk-users] 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 at 172.16.60.160:5060;user=phone SIP/2.0
Record-Route: <sip:10.25.153.150;lr;ftag=02e3a8c0-33807b-t-2>
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" <sip:39937841;cpc=payphone at
192.168.225.2:5060
;user=phone>;tag=02e3a8c0-33807b-t-2
To: <sip:D39539988120 at 192.168.225.2:5060;user=phone>
Call-ID: 2915b6e4-02e3a8c0-0000be53 at 192.168.225.2
CSeq: 2 INVITE
Contact:
<sip:10.1.1.10;line=sr-N6IAzBMsz.MwzxPfPxFsMJZfWBc7MBVuOBV-W.y6MxV*>
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"
<sip:39937841;cpc=payphone at 192.168.225.2:5060;user=phone>
Min-SE: 90
Privacy: none
Content-Type: application/sdp
Content-Length: 167
v=0
o=10.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=10.25.153.150;branch=z9hG4bK587.67258295.0
Via: SIP/2.0/UDP
10.1.1.10;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.qLOBF6zGZLMBj7MBvuMx3AMB1jmxuqC93X3heroEWvH9vsCFN43qdAMxyAMxyAMxyAMlMZMxpJ3lqwWxarW.gqWReJMEPA36juW6WBzR363RVA3Ejugx3*
Record-Route: <sip:10.25.153.150;lr;ftag=02e3a8c0-33807b-t-2>
Call-ID: 2915b6e4-02e3a8c0-0000be53 at 192.168.225.2
From: "39937841 39937841" <sip:39937841;cpc=payphone at
192.168.225.2
;user=phone>;tag=02e3a8c0-33807b-t-2
To: <sip:D39539988120 at 192.168.225.2;user=phone>
CSeq: 2 INVITE
Content-Length: 0
-- Executing [039988120 at from-external:1]
NoOp("PJSIP/sipp-00000000", "
H E L L O ! ! !") in new stack
-- Executing [039988120 at 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 at 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=10.25.153.150;branch=z9hG4bK587.67258295.0
Via: SIP/2.0/UDP
10.1.1.10;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.qLOBF6zGZLMBj7MBvuMx3AMB1jmxuqC93X3heroEWvH9vsCFN43qdAMxyAMxyAMxyAMlMZMxpJ3lqwWxarW.gqWReJMEPA36juW6WBzR363RVA3Ejugx3*
Record-Route: <sip:10.25.153.150;lr;ftag=02e3a8c0-33807b-t-2>
Call-ID: 2915b6e4-02e3a8c0-0000be53 at 192.168.225.2
From: "39937841 39937841" <sip:39937841;cpc=payphone at
192.168.225.2
;user=phone>;tag=02e3a8c0-33807b-t-2
To: <sip:D39539988120 at 192.168.225.2
;user=phone>;tag=b23cda89-931c-4a95-85c5-0ec8b03f895c
CSeq: 2 INVITE
Contact: <sip:172.16.60.160:5060>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL,
UPDATE, PRACK, MESSAGE, REFER, REGISTER
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 193
v=0
o=- 62708 4 IN IP4 172.16.60.160
s=Asterisk
c=IN IP4 172.16.60.160
t=0 0
m=audio 13644 RTP/AVP 8
c=IN IP4 172.16.60.160
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:150
a=sendrecv
<--- Received SIP request (703 bytes) from UDP:10.25.153.150:5060 --->
ACK sip:172.16.60.160:5060 SIP/2.0
Via: SIP/2.0/UDP 10.25.153.150:5060;branch=z9hG4bKcydzigwkX
Via: SIP/2.0/UDP
10.1.1.10;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.qLOBF6zGZLMBj7MBvuMx3AMB1jmxuq3w3X3heroEWvH9vsCFN43qdAMxyAMxyAMxyAMlMZMxpJWBeIME3ugSVwWx3A3BPAMxIqg.jZWxqL3BqwMRjsW.j*
Max-Forwards: 67
From: "39937841 39937841" <sip:39937841;cpc=payphone at
192.168.225.2:5060
;user=phone>;tag=02e3a8c0-33807b-t-2
To: <sip:D39539988120 at 192.168.225.2:5060
;user=phone>;tag=b23cda89-931c-4a95-85c5-0ec8b03f895c
Call-ID: 2915b6e4-02e3a8c0-0000be53 at 192.168.225.2
CSeq: 2 ACK
User-Agent: NetCentrex CCS Softswitch/7.16.0
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, INFO, PRACK, UPDATE, NOTIFY
Content-Length: 0
> 0x99694c0 -- Probation passed - setting RTP source address to
10.206.22.171:41040
-- Executing [039988120 at from-external:4]
Read("PJSIP/sipp-00000000",
"dataEntry,"why-no-answer-mystery",10,,1,4") in new stack
-- Accepting a maximum of 10 digits.
-- <PJSIP/sipp-00000000> Playing 'why-no-answer-mystery.alaw'
(language
'en')
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20140311/3a0d3cfc/attachment.html>
Matthew Jordan
2014-Mar-11 15:43 UTC
[asterisk-users] PJSIP - dtmf mode is not updated when the far end doesn't support rfc2833
On Tue, Mar 11, 2014 at 8:23 AM, Yaron Nachum <nachum.yaron at gmail.com> wrote:> 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? >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. -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org