[Home]

Summary:ASTERISK-12313: Incomming rfc2833 DTMF is not relayed via SIP INFO method
Reporter:Farid Mirbaha (farid)Labels:
Date Opened:2008-07-04 04:32:15Date Closed:2011-06-07 14:08:12
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_senddtmf
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk1.4-cli.txt
( 1) asterisk1.4-pcap
( 2) extensions.conf
( 3) sip.conf
Description:Please bare with me and excuse my ignorance as I am not a Asterisk Guru.

All digits of incomming rfc2833 DTMF signaling are recognized correctly (as far as  I can tell). The problem is that Asterisk seems to be relaying the DTMF to the destination as is (rfc2833) instead of sending SIP INFO messages.



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

The set-up:

Debian Linux 2.6.22-3-686 (Lenny)
Asterisk SVN-branch-1.4-r98467M

Nokia N95 phone -> Mediatrix ISDN Gateway -> Asterisk 1.4 -> NewStep Voip Appliance (CSN1)

In sip.conf the Mediatrix is set to dtmfmode=rfc and the CSN1 is set to dtmfmode=info.

In extentions.conf the dialing rule is:

exten => _9090126333,1,Answer
exten => _9090126333,2,WaitExten(60)
exten => _*XXXXXXXX.,1,Dial(SIP/csn/4440011100,29,D(${EXTEN}))

The Nokia device calls 9090126333 via GSM and transmits rfc28333 DTMF digits "*08999269511#" to the mediatrix gateway. The gateway relays the call via SIP to Asterisk. Now we would expect Asterisk to relay the DTMF via SIP INFO to the CSN1, but what happens is that it sends an invite containing rfc2833 DTMF.

I might be overseeing something very simple in the configuration or misunderstanding Asterisk's capabilities. Please advise.

Comments:By: Farid Mirbaha (farid) 2008-07-07 01:14:06

Can someone kindly look into this issue. Thanks.

By: Farid Mirbaha (farid) 2008-07-09 08:06:59

Reminder

By: Joshua C. Colp (jcolp) 2008-07-10 18:17:05

I see no issues here...

Asterisk attempts to call using the csn peer (it does NOT specify RFC2833 in the SDP) but the peer responds with a 404 Not Found. This all seems perfectly fine.

Can you clarify anymore on what you mean?

By: Farid Mirbaha (farid) 2008-07-11 01:54:28

Thanks and sorry for not being more specific. The CSN peer does not have a user plane and can therefor not recognize DTMF signals in RTP packets, hence 404 not found. What it needs to receive after the invite is seperate SIP INFO messages with DTMF content. Simillar to this:

INFO sip:2143302100@172.17.2.33 SIP/2.0
Via: SIP/2.0/UDP 172.80.2.100:5060
From: <sip:9724401003@172.80.2.100>;tag=43
To: <sip:2143302100@172.17.2.33>;tag=9753.0207
Call-ID: 984072_15401962@172.80.2.100
CSeq: 25634 INFO
Supported: 100rel
Supported: timer
Content-Length: 26
Content-Type: application/dtmf-relay
Signal= 1
Duration= 160

I was asuming that this what asterisk does in dtmfmode=info. Of course I might be totally wrong.

Your help is highly appreciated.

By: Farid Mirbaha (farid) 2008-07-13 09:11:32

I'm really sorry for having wasted your time. You are right, asterisk performed perfectly correct. For some reason the leading '0' was cut of from the caller ID. That's why the CSN answered with 401 not found. After having corrected that the DTMF signals where relayed correctly. Please close this ticket.

By: Eliel Sardanons (eliel) 2008-07-13 12:44:46

Closed as per user request.