Summary:ASTERISK-01597: Pressing # on a sip channel sends tone and gives error in rtp.c
Reporter:jas_williams (jas_williams)Labels:
Date Opened:2004-05-12 08:54:13Date Closed:2011-06-07 14:10:22
Versions:Frequency of
Environment:Attachments:( 0) sipdebug.txt
Description:Inbound call over chan_capi delivered to a sip extension with the following dial options Dial,(SIP/1234|20|tr)
when # is pressed the following error is generated
NOTICE[458771]: rtp.c:470 ast_rtp_read: Unknown RTP Codec 109 received
Comments:By: Mark Spencer (markster) 2004-05-12 10:22:32

Please provide the setup of the "sip debug" for the phone.

By: jas_williams (jas_williams) 2004-05-12 10:33:59

Sip debug uploaded including a # pressed after connect....


By: jas_williams (jas_williams) 2004-05-12 10:49:23

When the inbound call is over IAX or sip then the # transfer works without a problem also the # transfer works fine from the ISDN if dial is configured with a T

Eg. the caller can do # transfer eg ISDN>* but call receiver cannot perform # transfer when the originating channel is ISDN.

edited on: 05-12-04 09:51

By: Mark Spencer (markster) 2004-05-12 13:50:42

This is some sort of MSN buglet because 109 isn't even listed in the INVITE or 200 OK as a codec.  I suppose we could make it a log_debug or mask it, but the fact it's sending it is definitely an issue on the MSN side.

By: jas_williams (jas_williams) 2004-05-13 02:05:56

MSN ? What is msn this is a SIP hard phone, and all it is sending is a # tone no out of band signalling is going on, the warning is generated when the # key is pressed, I think the problem may be in the chan_capi DTMF code but I am not a coder yet so I can not resolve.

By: Mark Spencer (markster) 2004-05-13 15:57:53

Sorry, i misread (saw "MSN" thought that was the client).  in any case, the phone is sending us something on 109, but it's not in its SDP, ergo it is and has to be a bug on the device itself.  You can confirm by looking at an ethereal trace if you really want to.

By: jas_williams (jas_williams) 2004-05-14 03:24:45

Ok I shall ignore the warning, but currently * does not respond to the # transfer request, It does not seem to be listening for the # tone on this side of the call. It only happens in a chan_capi call, with chan_iax # transfer works fine. Also when using iax as the inbound path the warning does not appear in the console.


By: Mark Spencer (markster) 2004-05-15 00:17:21

Your endpoint is probably sending DTMF using payload type 109 instead of 101, even though we request it on 101, assuming you have dtmf=rfc2833.

By: Mark Spencer (markster) 2004-05-18 15:21:26

Any updates here?

By: jas_williams (jas_williams) 2004-05-19 07:39:47

DTMF tones send in band using rfc2833 using a g711 codec.

# key is not detected when pressed, same from this clent and another (SJPhone) SJPhone does not generate Warning. but # tone still not detected by *


By: Mark Spencer (markster) 2004-05-19 09:25:07

rfc2833 is NOT in-band, it's out of band.  If you're sending in-band you are NOT using rfc2833 to do it.  Some phones allow using both in-band and out of band but you MUST NOT do this or you will have problems whenever you convert back to PSTN.

By: jas_williams (jas_williams) 2004-05-19 09:37:09

OK I missunderstood, my phone is currently set as


in its configuration, under sip.conf it has no specific setting, I works without issue when the calls are inbound on an X100P and no errors are recorded and #transfer works. however when the inbound channel is capi then #transfer does not work.

By: Mark Spencer (markster) 2004-05-19 18:03:14

chan_capi is not part of asterisk and is not supported through the asterisk bug tracker.  having said that, i have no explanation as to why # transfer would not work with chan_capi.

By: Mark Spencer (markster) 2004-05-20 10:39:08

You could try doing in-band dtmf, incidently, instead of rfc2833 and see what happens.

By: jas_williams (jas_williams) 2004-05-20 12:45:45

Changed DTMF setting for phone to outband rather than inband(rfc8233) and # transfer works. Does this clarify anything ?


By: Mark Spencer (markster) 2004-05-21 23:13:00

It only clarifies insofar is it's clear it's an rfc2833 issue and seems to be tied to your SIP endpoint which is for some reason sending on 109 instead of 101 for the rfc2833 as we say in our invite.  Since you have a work around, we'll just call this one closed.