[Home]

Summary:ASTERISK-05687: RFC2833 DTMF detection not working on incoming PSTN->SIP->* calls (not bug 5780!)
Reporter:chotaire (chotaire)Labels:
Date Opened:2005-11-23 12:59:19.000-0600Date Closed:2006-02-14 15:33:32.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:In Asterisk Version 1.0.10 and 1.2.0 (and probably a few older versions), the following is giving us headache:

1. By POTS (e.g. ISDN or GSM) you dial a phone no. provided by a SIP provider.
2. The SIP provider will forward the call to your * box via SIP.
3. The * box takes the call and awaits DTMF input.
4. When configured with dtmfmode=rfc2833, * will not detect any single tone.

If doing it the other way around, it will work:

1. * places a phone call to a POTS phone number via a SIP provider.
2. The phone takes the call and the callee will hit DTMF tones.
3. When configured with dtmfmode=rfc2833, * will detect all tones.

Sorry for this lame description, but when discussing the problem on #asterisk, everybody had problems understanding the situation. Remember, the caller is *NOT* using a SIP phone, when using a SIP phone this stuff will work as intended. The caller is using a standard telephone with a POTS provider and will call a SIP phone number that ends up in *.

Now the funny thing: This worked perfectly with Asterisk version 1.0.3. Zeeek checked this and verified the problem, I'm "not alone" ;) It seems this has already been broken for ages and nobody found out.

****** ADDITIONAL INFORMATION ******

With my configuration, I have no alternatives to rfc2833. I am unable to use inband or info mode (info will do the same crap even in 1.0.3). Also, please note that this has nothing to do with bug 5780!!
Comments:By: twisted (twisted) 2005-11-23 23:19:58.000-0600

It sounds like your provider isn't converting them to rfc2833, or not respecting it and sending the tones inband.  Back then, we listened in both places, which was just silly.   Make absolutely sure your invite header from the provider into the asterisk box has a line similar to this:

m=audio 10000 RTP/AVP 0 4 8 101

that 101 tacked onto the end specifies that they are going to attempt to send you dtmf via rfc2833.

the same line,

m=audio 10000 RTP/AVP 0 4 8 0
or it's equivalent
m=audio 10000 RTP/AVP 0 4 8

means that the origination end of the sip message does not support (or at least want to use) rfc2833.

If the invite does not contain the rfc2833 portion, then we will discard it as unsupported on that end.
By: randulo (randulo) 2005-11-24 02:39:00.000-0600

I have the same problem and I just looked at your suggestion and tried it:

The 101 is there, the tones are not detected. DTMF works in IAX2 from the same provider (we have both types of account).

Date: Thu, 24 Nov 2005 08:30:22 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 345
v=0
o=root 25073 25073 IN IP4 213.161.nnn.nnn
s=session
c=IN IP4 213.161.nnn.nnn
t=0 0
m=audio 12184 RTP/AVP 0 8 97 3 18 4 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -


Sending to 213.161.nnn.nnn : 5060 (NAT)
Found peer 'directcentrex'
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 97
Found RTP audio format 3
Found RTP audio format 18
Found RTP audio format 4
Found RTP audio format 101
Peer audio RTP is at port 213.161.nnn.nnn:12184
Found description format PCMU
Found description format PCMA
Found description format iLBC
Found description format GSM
Found description format G729
Found description format G723
Found description format telephone-event
Capabilities: us - 0x104 (ulaw|g729),
peer - audio=0x50f (g723|gsm|ulaw|alaw|g729|ilbc)/video=0x0 (nothing),
combined - 0x104 (ulaw|g729)
Non-codec capabilities: us - 0x1 (telephone-event),
peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Looking for s in directcentrex-in (domain 213.223.nnn.nnn)
list_route: hop: <sip:0684726471@213.161.nnn.nnn>
Transmitting (NAT) to 213.161.nnn.nnn:5060:
SIP/2.0 100 Trying

I was assuming this wasn't the case in 1.0.9 but then I realized that I never used a DID from SIP, only IAX.

hope this helps
By: chotaire (chotaire) 2005-11-24 10:10:51.000-0600

twisted:
v=0
o=- 2347297 0 IN IP4 62.206.6.194
s=Cisco SDP 0
c=IN IP4 62.206.6.194
t=0 0
m=audio 16960 RTP/AVP 8 0 2 99 18 110
a=rtpmap:99 G726-24/8000
a=rtpmap:110 X-NSE/8000
a=fmtp:110 192-194,200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 110
a=X-cpar: a=rtpmap:110 X-NSE/8000
a=X-cpar: a=fmtp:110 192-194,200-202
a=X-cap: 2 image udptl t38


If they do not send me 101 but 110, what is the solution? I tested this with the three most known SIP providers (sipgate, 1&1, broadnet) in Germany, all without success. So what do I do if they do NOT attempt to send via rfc2833? Am I stuck with 1.0.3 and may never update or is someone going to patch this (maybe a patch already exists?). One thing is for sure, if they don't send via rfc2833, there must be an config option to allow listening in both places (like 1.0.3 did), because there are millions of people out there who then have no alternatives.

PS: Using inband will cause havoc in meetme and other occasions.


By: Mark Spencer (markster) 2005-11-25 13:00:25.000-0600

Are you on irc?  Perhaps you can find me there and I can login to your system and look (i'm "kram")
By: Mark Spencer (markster) 2005-11-25 15:24:50.000-0600

Also, can you run an ethreal dump to confirm that the far end is actually sending us digits?
By: randulo (randulo) 2005-11-26 11:59:52.000-0600

FWIW, Mark et al, I found that the problem I had was that one SIP provider was NOT sending the 101 and the one that was which I tested, it was the cellphone company that mde the difference, because today I did a tcpdump and when I tried the tones on a normal phone, they did work.

This is a typical situation though, where a lot of users wouldn't see this problem because:

a) they use IAX2 for DID
b) they don't do IVR or anything witj tones on incoming SIP

Randy (randulo)
By: chotaire (chotaire) 2005-12-05 11:51:57.000-0600

kram: you can always spot me in #asterisk with the nickname "Chotaire". I am looking forward to talk to you. I have found out more occasions where the DTMF behaviour is very strange, testing tons of SIP providers. I still think this is an issue that demands a few changes and I'd be happy to explain you why... I'll have SIP accounts for you to test with and find out why this is a problem. Furthermore, I found out there are a few unwanted behaviours inside meet-me's that can be abused. Let's talk. Have a nice week.
By: Olle Johansson (oej) 2006-01-09 14:40:36.000-0600

Any updates on this MAJOR bug?


/Housekeeping
By: Max (tintin) 2006-01-26 09:11:21.000-0600

Would be great if this could be solved. The problem appears to be Meetme related as incoming calls via the same VoIP provider: POTS -> DID at VoIP Provider -> SIP -> * and DTMF detection via WaitExten() for example works fine !?


By: Kevin P. Fleming (kpfleming) 2006-02-14 15:33:30.000-0600

As the bug posting guidelines clearly demand, there is absolutely no way we can debug a SIP problem with a complete call trace showing the problem occurring. On top of that, there is no way a DTMF detection problem is "MeetMe related"... app_meetme has nothing to do with DTMF detection.

If you can provide a complete proper trace (uploaded as an attachment) of a call, including 'sip debug' and 'rtp debug', and show that Asterisk receives the RFC2833 packets but does not process them, then you can request this bug to be reopened.