Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.




17 posts

Geek


Topic # 68411 21-Sep-2010 14:15
Send private message

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?

View this topic in a long page with up to 500 replies per page Create new topic
 1 | 2
3421 posts

Uber Geek
+1 received by user: 408

Trusted

  Reply # 382697 21-Sep-2010 14:23
Send private message

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





3594 posts

Uber Geek
+1 received by user: 79

Trusted
WorldxChange

  Reply # 382702 21-Sep-2010 14:41
Send private message

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 Wink

             

https://www.facebook.com/wxccommunications

 
 
 
 


3594 posts

Uber Geek
+1 received by user: 79

Trusted
WorldxChange

  Reply # 382706 21-Sep-2010 14:50
Send private message

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 Wink

             

https://www.facebook.com/wxccommunications



17 posts

Geek


  Reply # 382735 21-Sep-2010 15:40
Send private message

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.

3594 posts

Uber Geek
+1 received by user: 79

Trusted
WorldxChange

  Reply # 382765 21-Sep-2010 16:31
Send private message

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 Wink

             

https://www.facebook.com/wxccommunications



17 posts

Geek


  Reply # 382768 21-Sep-2010 16:34
Send private message

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

873 posts

Ultimate Geek
+1 received by user: 55

Subscriber

  Reply # 382858 21-Sep-2010 19:58
Send private message

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

3594 posts

Uber Geek
+1 received by user: 79

Trusted
WorldxChange

  Reply # 382977 22-Sep-2010 05:58
Send private message

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 Wink

             

https://www.facebook.com/wxccommunications



17 posts

Geek


  Reply # 383394 23-Sep-2010 00:27
Send private message

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.



17 posts

Geek


  Reply # 384002 24-Sep-2010 11:55
Send private message

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



17 posts

Geek


  Reply # 386718 1-Oct-2010 13:18
Send private message

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

3594 posts

Uber Geek
+1 received by user: 79

Trusted
WorldxChange

  Reply # 386770 1-Oct-2010 14:41
Send private message

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 Wink

             

https://www.facebook.com/wxccommunications



17 posts

Geek


  Reply # 386943 1-Oct-2010 22:04
Send private message

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.

27255 posts

Uber Geek
+1 received by user: 6688

Moderator
Trusted
Biddle Corp
Lifetime subscriber

  Reply # 386946 1-Oct-2010 22:16
Send private message

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.





17 posts

Geek


  Reply # 386955 1-Oct-2010 22:37
Send private message

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
View this topic in a long page with up to 500 replies per page Create new topic



Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.