Summary:	ASTERISK-14167: [patch] Annoying "Unknown RTP codec 126 received" messages confuse people
Reporter:	John Covert (jcovert)	Labels:
Date Opened:	2009-05-19 12:51:50	Date Closed:	2011-06-07 14:08:16
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20090825__issue15157.diff.txt ( 1) rtp.c.patch ( 2) rtp.c.patch-w-debug
Description:	The X-Lite Softphone, one of the most commonly used softphones on Asterisk, sends RTP codec 126 messages, which annoy and confuse users who are running with verbosity set to 3, the most likely verbosity setting for watching a system in operation. I propose: a. modifying main/rtp.c to test VERBOSITY_ATLEAST(4) prior to the call to ast_log(LOG_NOTICE, "Unknown RTP codec %d received from...",...) b. (and/or possibly) explicitly ignoring 126 no matter what the verbosity. I will generate a patch in the next two or three days; in the interim I welcome any comments. I also note that in trunk rtp.c has been replaced by rtp_engine.c; I have not yet determined whether a similar issue exists.  Comments? Regards/john
Comments:	By: Tilghman Lesher (tilghman) 2009-05-19 14:42:13 Why not simply disable NOTICE messages to the console in logger.conf? By: Tilghman Lesher (tilghman) 2009-05-19 14:43:51 Neither of your two suggestions will be committed:  1) these messages are NOTICE, not WARNING or ERROR, so they are already at a level where they can be ignored, and 2) combining LOG level messages with VERBOSE levels is not a welcome change. By: John Covert (jcovert) 2009-05-19 14:52:44 >Why not simply disable NOTICE messages to the console in logger.conf? Seems like a big hammer. I'll concede that (a) should not be done. (b) was  an "and/or".  Taking it as an "instead of", please consider whether it should be committed.  126 isn't "unknown"; it's a well-known message from X-Lite clients, and need not generate any NOTICE messages at all.  It should be recognized and ignored. /john By: Leif Madsen (lmadsen) 2009-05-20 07:20:08 NOTICE messages aren't typically disabled in the console in order to track for potential issues. Why can't this simply be moved to a DEBUG message? By: John Covert (jcovert) 2009-05-20 07:27:07 Even if it is moved to a DEBUG message, I still think 126 should not generate any message at all, since it is a known thing that X-Lite does, and does FREQUENTLY, filling up log files: [May 19 20:49:41] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:49:51] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:50:02] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:50:12] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:50:14] NOTICE[12771] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:50:22] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:50:33] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:50:43] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:50:53] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:51:04] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:51:14] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:51:24] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:51:35] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:51:45] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:51:55] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:52:06] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:52:13] NOTICE[12771] rtp.c: Unknown RTP codec 126 received from ... [May 19 20:52:16] NOTICE[12765] rtp.c: Unknown RTP codec 126 received from ... But at least as a DEBUG it would only fill up log files if someone sets the DEBUG level greater than zero. By: Tilghman Lesher (tilghman) 2009-05-20 09:45:23 Yes, but this isn't an Asterisk problem, per se.  It's an X-Lite problem that they did not first negotiate codec 126 in the SIP dialog before sending it.  It is explicitly a violation of the SIP specification to send an non-negotiated codec, and we WANT to know when that happens, so we can inform vendors to fix their clients. By: Leif Madsen (lmadsen) 2009-05-21 09:55:02 I'm closing this issue as while it appears this could be an annoyance, I do agree with Tilghmans assessment. By: John Covert (jcovert) 2009-05-21 10:18:02 I just wanted to crosslink this to a topic in the CounterPath forum. http://forums.counterpath.com/viewtopic.php?f=6&t=12552&p=55108#p55108 That topic links back to here as well.  And I will follow up with CounterPath if possible to actually get this fixed; it is putting hundreds of messages an hour into the messages log file (and yes, that could be disabled too, but we don't want to disable notices in case something really important happens). Feel free to close it again. /john By: John Covert (jcovert) 2009-05-21 11:58:21 Sorry, Leif and Brian, but the RTP spec (RFC 3550) clearly says that the receiver is to ignore any RTP payload types which it does not understand. in order to comply with the RTP spec, the NOTICE needs to be removed or at least changed to a DEBUG. I am attaching a tested patch which removes the NOTICE. 5. RTP Data Transfer Protocol 5.1 RTP Fixed Header Fields ... payload type (PT): 7 bits This field identifies the format of the RTP payload and determines its interpretation by the application. A profile MAY specify a default static mapping of payload type codes to payload formats. Additional payload type codes MAY be defined dynamically through non-RTP means (see Section 3). A set of default mappings for audio and video is specified in the companion RFC 3551 [1]. An RTP source MAY change the payload type during a session, but this field SHOULD NOT be used for multiplexing separate media streams (see Section 5.2). A receiver MUST ignore packets with payload types that it does not understand. Thank you/john By: John Covert (jcovert) 2009-05-21 12:05:03 Additional info: There is a draft IETF spec for keep-alives http://tools.ietf.org/html/draft-ietf-avt-app-rtp-keepalive-05 which states:   The RECOMMENDED solution is thus the "RTCP packets multiplexed with   RTP packets" (Section 4.3).  However, when this mechanism cannot be   negotiated, it is RECOMMENDED to use the fallback "RTP Packet with   Unknown Payload Type" mechanism (Section 4.6) as it will always work. By: Jared Smith (jsmith) 2009-05-21 13:47:37 Here are my two cents: 1) While it's a hackish form of NAT keepalive, the unknown payload type RTP packets are gaining more and more traction in the SIP community 2) Obviously Asterisk is just printing notices, which wouldn't be too bad, except that it does tend to fill up the log files much more quickly than I would like to see happen. Tilghman (or any other -devs), would you be amenable to a config option in rtp.conf that simply suppressed the notices for this particular situation?  I think it's a reasonable compromise... By: Dmitry Andrianov (dimas) 2009-05-22 02:59:16 jcovert, "Sorry, Leif and Brian, but the RTP spec (RFC 3550) clearly says that the receiver is to ignore any RTP payload types which it does not understand." Well technically, Asterisk ignores these packets so there is NO violation of any kind. Unless you can point me out where RFC requires not writing anything to the log file in this situation :) However I would agree, this message better be logged as DEBUG level 1 instead of NOTICE. And I personally would prefer it over having one more configuration option... By: Leif Madsen (lmadsen) 2009-05-22 06:53:22 Changing to feedback for anyone who wishes to comment further. At this point, my recommendation is for the NOTICE to be moved to a DEBUG. I'd suggest a debug level of 2 or 3 since it could be quite noisy. By: John Covert (jcovert) 2009-05-22 07:42:12 A quick look at other DEBUGs in the module indicates that level 3 are the most similar type. I've provided another patch. By: Tilghman Lesher (tilghman) 2009-08-25 17:51:39 This needs to be sent to the -dev list for discussion, prior to commit. By: Tilghman Lesher (tilghman) 2009-09-10 16:55:37 Since nothing has been sent to the -dev list, I'm assuming that the reporter has lost interest.