Summary:	ASTERISK-02986: Cisco's RTP codec type 100
Reporter:	ajlow (ajlow)	Labels:
Date Opened:	2004-12-14 05:23:45.000-0600	Date Closed:	2011-06-07 14:10:23
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	My logs have been filling up dramatically recently since we plugged a couple of 4.0 Cisco Call Managers into Asterisk. It seems that an issue which seems to have been discovered a couple of years ago is hitting me now: http://www.marko.net/asterisk/archives/0211/0038.html Simply this is Cisco pumping out a payload type of 100 which apparently is equivelant to RFC2833 DTMF. I've added this payload type 100 and all seems to be working well but I suspect there is a reason why we do not see this in the 1.0.3 release, anybody have any ideas ???
Comments:	By: ajlow (ajlow) 2004-12-14 05:29:57.000-0600 Patch will be uploaded if applicable. By: Mark Spencer (markster) 2004-12-18 18:41:22.000-0600 Is it negotiated in RTP? By: Brian West (bkw918) 2004-12-18 18:48:47.000-0600 I was thinking it should be but looking at the code I don't see where we parse it out mark can you point that out to me? bkw By: Andrey S Pankov (casper) 2004-12-21 06:46:40.000-0600 There is no pt=100 support in * and I'm about to be sure cisco uses pt=100 for e.g. modempass faxing and other propietary things (payload type is configurable in cisco GWs, www.cisco.com has more details). Moreover, UDP packets with pt=100 used for modempass faxing (cisco NSE packets) are not standart, they have 2 extra bytes at the end of packet (maybe other packets too [96,100-1xx]). Here is UDP only part: 40 00 2e da 00 18 b6 5d  80 64 67 cd 00 40 ec 00 9e 78 28 34 c0 00 00 00  00 00 Source port: 0x4000 Dest port: 0x2eda Length: 0x0018 (24 bytes) Checksum: 0xb65d (correct) !!! <skip, but payload type is 100, trust me ;)> Payload: 0xc0000000 and (!!!) extra 0x0000 at the end. Work on this issue has been started, but the issue is not completely investigated yet. markster: This may or may not be negotiated. E.g. when cisco ATA is configured for modempass faxing using [no matter] MGCP, SIP or H.323 it sends NSE packet with pt=100 regardless of successfull negotiation. Moreover, I think for e.g. H.323 there is no possibility to indicate modempass in capabilities (never seen) . And for SIP there is "a=rtpmap:100 X-NSE/8000" in SDP part (not sure this is a standart way or cisco proprietary). Never seen cisco indicating NSE in MGCP CRCX or MDCX, maybe I'm not right here. So, even adding "if (pt==100)" with process_rfc2833 will not solve the problem. By: Andrey S Pankov (casper) 2004-12-22 11:54:54.000-0600 Maybe it's worth to add possibility to pass transparently RTP packets * does not understand? Any backside effects then??? Anyway, this may be configurable in rtp.conf Had been there any design considerations when it was decided to just drop packets with payload types unknown to asterisk? By: dbruce (dbruce) 2004-12-22 17:22:52.000-0600 It should be noted the NSE is a Cisco proprietary signalling method, and stands for "Named Signalling Event". It's use is controlled by bits 7 through 15 of the connectmode parameter on an ATA18X. The auidomode parameter of the Cisco device has bits for controlling FAX detection. NSE is Cisco's implimentation of ITU TR-30/02-01-010 "In-band State Event Signaling for MoIP" (http://ftp.tiaonline.org/tr-30/tr30MAIN/Public/2002%20Contributions/00201010.doc) (SSE - State Signalling Events). It is roughly equivilent to the telephone-event that devices send for DTMF, except that Cisco uses it for both DTMF and FAX/Modem detection. In IOS versions above 12.1(13) (approximately), Cisco added support for the more commonly supported RFC2833 DTMF detection (although they did manage to botch the implimentation so Asterisk needs specific code to deal with it properly), and NSE has, in the magority of cases, been relegated to FAX/Modem passthrough, and usually reception of a NSE packet is an indication that the device wants to force a codec change. The payload values represent: 0xC0 :: Shift to voiceband data mode 0xC1 :: Disable echo cancellation 0xC2 :: Shift to voice mode 0xC8 :: Shift to fax relay mode 0XC9 :: Positive acknowledgement of Cisco NSE 0xCA :: Negative acknowledgement of Cisco NSE (see: http://www.iana.org/assignments/media-types/audio/vnd.cisco.nse) The biggest obstacle to supporting NSE is that when the Cisco device forces a codec change due to fax passthrough, it also changes the packetization interval from the standard 20ms to 10ms. Until support for NSE is developed, the correct way to handle an NSE event would be to respond to the packet with NACK so the device knows that it's request has not been acted upon. edited on: 12-22-04 17:25 By: Andrey S Pankov (casper) 2004-12-23 05:53:14.000-0600 And what about fax relay with payload type 96 and 97? http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax_c/voipt_c/vts_fax.htm By: Clod Patry (junky) 2005-01-07 00:20:06.000-0600 Is there any development in here? it makes ~2weeks of inactivity. Please post something or that bug will be forced to be close. Thanks By: Mark Spencer (markster) 2005-01-07 00:25:24.000-0600 I'm leary of merging this because it's not being negotiated within the SDP. By: Andrey S Pankov (casper) 2005-01-10 07:48:38.000-0600 It's not clear for now what to develop and there is almost no discussion on this topic here... so, let's close this bug. By: Clod Patry (junky) 2005-01-10 08:10:16.000-0600 reporter seems to have lost interest. If someone wants more discussion related to this bug, feel free to re-open it.