[WXC/VFX] DTMF from Asterisk not working... anyone else seen this?

Forums › One NZ (including Farmside) › [WXC/VFX] DTMF from Asterisk not working... anyone else seen this?

A1kmm

17 posts

Geek
Inactive user

#68411 21-Sep-2010 14:15

Hi all,

I've just recently switched to VFX, and have calls in and out working from Asterisk - but not DTMF tones out.

I've read this previous thread with someone with a similar issue, but it doesn't appear to apply here (http://www.geekzone.co.nz/forums.asp?forumid=65&topicid=18001).

My SIP INVITE being sent from Asterisk to the VFX SIP server (slightly censored) looks like this:
"
INVITE sip:0800113355@pan.wxnz.net:5060 SIP/2.0
Via: SIP/2.0/UDP 125.237.88.71:5060;branch=z9hG4bK19e5d7ba;rport
Max-Forwards: 70
From: <deleted>
To: <sip:0800113355@pan.wxnz.net:5060>
Contact: <sip:<deleted>@125.237.88.71>
Call-ID: 6ea2bf9f4619d4b14a25c7723b5f804b@125.237.88.71
CSeq: 103 INVITE
User-Agent: Asterisk PBX 1.6.2.5-0ubuntu1
Authorization: <deleted>
Date: Tue, 21 Sep 2010 01:40:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 295

v=0
o=root 958132852 958132853 IN IP4 125.237.88.71
s=Asterisk PBX 1.6.2.5-0ubuntu1
c=IN IP4 125.237.88.71
t=0 0
m=audio 14900 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
"
The RTP telephone-event (101 - i.e. RFC2833) payload type is in there.

The 101 payload type is also in the Progress and OK responses from the server.

My end is then sending out the DTMF tones...
868    23.565222    10.1.1.5    58.28.20.150    RTP EVENT    Payload type=RTP Event, DTMF One 1
Packet details follow:
"Real-Time Transport Protocol
    [Stream setup by SDP (frame 73)]
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    0... .... = Marker: False
    Payload type: telephone-event (101)
    Sequence number: 63946
    [Extended sequence number: 129482]
    Timestamp: 3989419480
    Synchronization Source identifier: 0x4856b379 (1213641593)"

RFC 2833 RTP Event
    Event ID: DTMF One 1 (1)
    1... .... = End of Event: True
    .0.. .... = Reserved: False
    ..00 1010 = Volume: 10
    Event Duration: 1440

870    23.565278    10.1.1.5    58.28.20.150    RTP EVENT    Payload type=RTP Event, DTMF One 1
...
881    23.669619    10.1.1.5    58.28.20.150    RTP EVENT    Payload type=RTP Event, DTMF One 1 (end)

However, it seems that the VFX system isn't passing the DTMF out to other services (e.g. Kiwibank).

Looking at the packets, everything looks right at my end - is this an issue for everyone, or is there something I can change at my end to make it work?

1 | 2

3926 posts

Uber Geek
+1 received by user: 759

Trusted

#382697 21-Sep-2010 14:23

I had this problem a couple of years ago. Could you post your trunk config?

Speedtest 2019-10-14

maverick

3594 posts

Uber Geek
+1 received by user: 80

Trusted

WorldxChange

#382702 21-Sep-2010 14:41

Try setting your DTMF to this

a=fmtp:101 0-15

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

maverick

3594 posts

Uber Geek
+1 received by user: 80

Trusted

WorldxChange

#382706 21-Sep-2010 14:50

If you make the call again I will check your DTMF to see if we see it

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

A1kmm

17 posts

Geek
Inactive user

#382735 21-Sep-2010 15:40

The 0-16 (as opposed to 0-15) is hard-coded into Asterisk - see the source at:
http://svnview.digium.com/svn/asterisk/trunk/channels/chan_sip.c?revision=287646&view=markup#l10311

People need to compile to change that, or do what I did and modify the binary in a hex editor anyway :P

It still doesn't work with this change however.

It now sends:
"
Session Initiation Protocol
Request-Line: INVITE sip:0800113355@pan.wxnz.net:5060 SIP/2.0
Method: INVITE
Request-URI: sip:0800113355@pan.wxnz.net:5060
Request-URI User Part: 0800113355
Request-URI Host Part: pan.wxnz.net
Request-URI Host Port: 5060
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 125.237.88.71:5060;branch=z9hG4bK6760e209;rport
Transport: UDP
Sent-by Address: 125.237.88.71
Sent-by port: 5060
Branch: z9hG4bK6760e209
RPort: rport
Max-Forwards: 70
From:
SIP Display info:
SIP from address:
SIP from address User Part:
SIP from address Host Part: 125.237.88.71
SIP tag: as5e3f3fd4
To:
SIP to address: sip:0800113355@pan.wxnz.net:5060
SIP to address User Part: 0800113355
SIP to address Host Part: pan.wxnz.net
SIP to address Host Port: 5060
Contact: @125.237.88.71>
Contact Binding: @125.237.88.71>
URI: @125.237.88.71>
SIP contact address: sip:@125.237.88.71
Call-ID: 0874b72a4c0bc7163937f9f643bee5ad@125.237.88.71
CSeq: 103 INVITE
Sequence Number: 103
Method: INVITE
User-Agent: Asterisk PBX 1.6.2.5-0ubuntu1
Authorization: Digest username="", realm="xport.co.nz", algorithm=MD5, uri="sip:0800113355@pan.wxnz.net:5060", nonce="", response="", qop=auth, cnonc
Authentication Scheme: Digest
Username: ""
Realm: "xport.co.nz"
Algorithm: MD5
Authentication URI: "sip:0800113355@pan.wxnz.net:5060"
Nonce Value: ""
Digest Authentication Response: ""
QOP: auth
CNonce Value: ""
Nonce Count: 00000001
Date: Tue, 21 Sep 2010 03:29:23 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 297
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): root 1154278102 1154278103 IN IP4 125.237.88.71
Owner Username: root
Session ID: 1154278102
Session Version: 1154278103
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 125.237.88.71
Session Name (s): Asterisk PBX 1.6.2.5-0ubuntu1
Connection Information (c): IN IP4 125.237.88.71
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 125.237.88.71
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 19476 RTP/AVP 18 101
Media Type: audio
Media Port: 19476
Media Protocol: RTP/AVP
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Sample Rate: 8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute Fieldname: fmtp
Media Format: 18 [G729]
Media format specific parameters: annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-15
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-15
Media Attribute (a): silenceSupp:off - - - -
Media Attribute Fieldname: silenceSupp
Media Attribute Value: off - - - -
Media Attribute (a): ptime:20
Media Attribute Fieldname: ptime
Media Attribute Value: 20
Media Attribute (a): sendrecv
"

...

"
User Datagram Protocol, Src Port: 19476 (19476), Dst Port: 35396 (35396)
Source port: 19476 (19476)
Destination port: 35396 (35396)
Length: 24
Checksum: 0xba71 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Real-Time Transport Protocol
[Stream setup by SDP (frame 310)]
[Setup frame: 310]
[Setup Method: SDP]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: telephone-event (101)
Sequence number: 57292
[Extended sequence number: 57292]
Timestamp: 811962968
Synchronization Source identifier: 0x224ac8d7 (575326423)
RFC 2833 RTP Event
Event ID: DTMF One 1 (1)
1... .... = End of Event: True
.0.. .... = Reserved: False
..00 1010 = Volume: 10
Event Duration: 1440
"

Note that I know that the NAT is working correctly, as the other RTP frames (such as G.729 voice) make it out successfully.

maverick

3594 posts

Uber Geek
+1 received by user: 80

Trusted

WorldxChange

#382765 21-Sep-2010 16:31

The first 2 calls that you made what numbers did you push ?

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

A1kmm

17 posts

Geek
Inactive user

#382768 21-Sep-2010 16:34

1 both times - repeatedly after the call connected. I can see the numbers being sent out in the RTP.

New World

Shop on-line at New World now for your groceries (affiliate link).

rphenix

990 posts

Ultimate Geek
+1 received by user: 127

ID Verified

Lifetime subscriber

#382858 21-Sep-2010 19:58

Try DTMF = auto in your trunk definition for some strange reason that seems to work better than rfc2833 I've found recently.

maverick

3594 posts

Uber Geek
+1 received by user: 80

Trusted

WorldxChange

#382977 22-Sep-2010 05:58

A1kmm: 1 both times - repeatedly after the call connected. I can see the numbers being sent out in the RTP.

hmmm not a 1

DTMF

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

A1kmm

17 posts

Geek
Inactive user

#383394 23-Sep-2010 00:27

It is definitely sending a '1' - I have even tried calling myself, and I get the correct digits back through your server. I've tried tweaking the Asterisk conf to use dtmfmode=auto - it makes no difference.

I've also tried making several source code changes to Asterisk - changing the DTMF volume (which was hard coded at 10, to the maximum of 31), reducing the number of packets Asterisk sends (as it sends extra packets in case some get lost) so it only sends one RFC2833 start and one end packet - still no luck. I've also tried setting the duration of the end packet to 100 and 300 ms as it was longer - also doesn't help.

A1kmm

17 posts

Geek
Inactive user

#384002 24-Sep-2010 11:55

I got it going by sending out SIP INFO rather than RFC2833 - obviously the Xnet hardware isn't configured to accept RFC2833 from
Asterisk (it seems to send them back to VFX users, but not to anyone else).

However, SIP INFO does work.

To get this working, you simply need to add dtmfmode = info to the VFX peer in sip.conf

A1kmm

17 posts

Geek
Inactive user

#386718 1-Oct-2010 13:18

Except that it stopped working again - now I get "Unsupported media type" for SIP INFO requests.

Lego

Shop now for Lego sets and other gifts (affiliate link).

maverick

3594 posts

Uber Geek
+1 received by user: 80

Trusted

WorldxChange

#386770 1-Oct-2010 14:41

but you have made changes have you not ?

You were running ..... Asterisk PBX 1.6.2.5-0ubuntu1 and now it's Asterisk PBX 1.6.2.13,

Did your 125 calls work on the 27th this is an IVR service and the call duration 8 minutes suggest you got through fine.

This call does not use sip info for dtmf, as I pointed out rfc2833 should be fine and is the standard

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

A1kmm

17 posts

Geek
Inactive user

#386943 1-Oct-2010 22:04

The order of events:
Ubuntu binaries - out of the box - with dtmfmode = rfc2833: DTMF doesn't work.
Made a modification to the binary to change RFC2833 string as per my comment on 21st - DTMF still doesn't work.
Built latest stable Asterisk from source, dtmfmode = rfc2833: DTMF still doesn't work.
Tried a few source code modifications to rfc2833 with latest Asterisk - DTMF not working.
Changed dtmfmode = info (with the version of Asterisk I built myself) - got it working.
Tried today after not sending any DTMF for a while - no longer working (nothing changed on my end from when it was working).
Tried dtmfmode = rfc2833 - not working. Reverted my changes to RFC2833 support in Asterisk to pristine version - still not working.
Tried dtmfmode = inband (which is not supposed to work reliably with G.729, but it worked well enough for Kiwibank to recognise a 1). I also tried with my old ISP / phone provider's 0800 number (08004WOOSH) since I had to call them to sort a few things out - pressing DTMF 3 in inband mode causes the call to terminate immediately from their end (that is likely a problem with their system I guess?)

So the only configs I've ever had working are:
SIP INFO on Asterisk 1.6.2.13 (worked for a while but then stopped).
inband on Asterisk 1.6.2.13 (calls consistently terminate after receiving DTMF for one number - not sure if it is a systemic problem with other providers - the same number works fine from my cellphone with DTMF however). Works for Kiwibank at least despite inband not being recommended over G.729.

sbiddle

30853 posts

Uber Geek
+1 received by user: 9996

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#386946 1-Oct-2010 22:16

WxC certainly do support RFC2833. I've also never come across a single DTMF issue ever with an Asterisk install.

I'm fully aware of the bugs that have existed over time but have never encountered a single issue with any install providing both handsets and Asterisk are set to RFC2833.

What type of handset are you using? I'd be highly suspicious of this being the cause of your issues and not Asterisk. The issue is certainly not with WxC.

A1kmm

17 posts

Geek
Inactive user

#386955 1-Oct-2010 22:37

Hi sbiddle, I've tried it with SFLPhone (and several other Free SIP phones), and also with a Linksys SPA2102 ATA (registered with my Asterisk and connected to two different models of PSTN FXS phones).

However, internally I use SIP INFO entirely - Asterisk translates from SIP INFO to RFC2833 when sending calls from internal phones to the WxC trunk via the Dial() application.

I know Asterisk is sending out the RFC2833 telephone-event RTP packets to WxC, because I can see them if I use a packet sniffer like Wireshark. The RFC2833 events get forwarded back to me if I call myself via WxC, but don't work on external services.

Is it possible that your configs which worked had DTMF inband being sent? My Asterisk is configured to filter out inband DTMF (because it looks for feature codes for internal transfers etc...) but I don't think the ATA does - if you didn't have feature codes enabled in your Dial() application call, it is possible that it worked for you because the inband tones got through and the RFC2833 made no difference. It is also possible that WxC has more than one config on their trunks - that would explain why SIP INFO worked and then stopped working for me.

1 | 2