[asterisk-users] DTMF

Jeff LaCoursiere jeff at jeff.net
Fri Apr 17 16:42:04 CDT 2009


On Fri, 17 Apr 2009, Jeff LaCoursiere wrote:

>> I went ahead and switched to SIP just for grins, and made sure
>> "dtmfmode=rfc2833" is in the peer config on both sides and in the entry
>> for the phone.  So now it is:
>>
>> polycom501---SIP/ulaw--->ast1---SIP/g729--->ast2---IAX/ulaw--->ITSP

A bit more information.  ast1 is running 1.4.23.1 and I noticed a debug 
line in rtp.c:

         if (rtpdebug || option_debug > 2)
                 ast_log(LOG_DEBUG, "- RTP 2833 Event: %08x (len = %d)\n", 
event, len);

So I set debug to 10 and caught this line:

[Apr 17 17:28:02] DEBUG[27264] rtp.c: - RTP 2833 Event: 00000002 (len = 4)

So I guess that proves that from the phone to ast1 RFC2833 is in effect (I 
did actually press the digit '2', which I assume is the event code 
above?).

I tried to do the same on ast2, which is running 1.4.22.1, and with debug 
set to 10 I did *not* get this message, which makes me think that RCF2833 
is NOT in effect for the trunk between ast1 and ast2.  Is that reasonable?

I'm not sure how to force such a thing other than what I have already 
done.  The peer entry on ast1:

[JBT-Dal-SIP]
disallow=all
host=XXXX
username=XXXX
secret=XXXX
type=peer
qualify=1000
dtmfmode=rfc2833
allow=g729
allow=gsm
allow=ulaw

The matching peer entry on ast2:

[ahrsip] ; AH Riise in St Thomas
type=friend
username=XXXX
host=dynamic
secret=XXXX
transfer=no
context=from-ahriise
disallow=all
allow=g729
allow=gsm
allow=ulaw
qualify=1000
dtmfmode=rfc2833

Am I missing something?

Thanks,

j


>>
>> looking at DTMF debug on ast2 I have:
>>
>> [Apr 17 15:18:06] DTMF[21585]: channel.c:2226 __ast_read: DTMF begin '5'
>> received on SIP/ahriise-0882f470
>> [Apr 17 15:18:06] DTMF[21585]: channel.c:2236 __ast_read: DTMF begin
>> passthrough '5' on SIP/ahriise-0882f470
>> [Apr 17 15:18:07] DTMF[21585]: channel.c:2148 __ast_read: DTMF end '5'
>> received on SIP/ahriise-0882f470, duration 200 ms
>> [Apr 17 15:18:07] DTMF[21585]: channel.c:2195 __ast_read: DTMF end
>> accepted with begin '5' on SIP/ahriise-0882f470
>> [Apr 17 15:18:07] DTMF[21585]: channel.c:2211 __ast_read: DTMF end
>> passthrough '5' on SIP/ahriise-0882f470
>>
>> Does this look like inband or out of band signaling?
>
> Looking at it a little closer, some of the debug lines look different:
>
> [Apr 17 15:18:07] DTMF[7041]: channel.c:2226 __ast_read: DTMF begin '1'
> received on SIP/ahriise-0882f470
> [Apr 17 15:18:07] DTMF[7041]: channel.c:2230 __ast_read: DTMF begin
> ignored '1' on SIP/ahriise-0882f470
> [Apr 17 15:18:07] DTMF[21585]: channel.c:2148 __ast_read: DTMF end '1'
> received on SIP/ahriise-0882f470, duration 200 ms
> [Apr 17 15:18:07] DTMF[21585]: channel.c:2184 __ast_read: DTMF begin
> emulation of '1' with duration 200 queued on SIP/ahriise-0882f470
> [Apr 17 15:18:07] DTMF[21585]: channel.c:2296 __ast_read: DTMF end
> emulation of '1' queued on SIP/ahriise-0882f470
>
> Emulation?  I am getting more confused by the moment.
>
> j
>
>>
>> I am starting to think the issue is actually at the ITSP, as I saw every
>> digit I pressed in the CLI on ast2, and yet the AT&T conference line I was
>> calling only recognized 3 out of six digits.
>>
>> Thanks,
>>
>> j
>>
>>
>> _______________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>



More information about the asterisk-users mailing list