Asterisk-Dev: Patch 2570: More verbose RTP debugging

Filip Olsson has posted details of a patch to allow more verbose RTP debugging:

Hi guys,

I've posted a patch in #2570 for doing _some_ more verbose RTP-debugging. It adds the CLI commands 'rtp debug [ip host[:port]]' and 'rtp no debug'. It works pretty much the same way sip debug does.

Here's some output:
Got RTP packet from 10.0.0.37:8000 (type 0, seq 4041, ts 1771635040, len 160)
Sent RTP packet to 10.0.0.38:8002 (type 0, seq 8584, ts 88800, len 160)

Here you can see the payload type(more or less the codec), sequence number, timestamp and the size of the packet.

It's handy to have when trying to figure out where those RFC2833 packets are going and why it's not working.

Please test the patch and give me feedback on additional features you'd like to see in it or anything else such as that you would like to resolve the PT in the output. Put warnings up when we see a jump in sequence numbers? This would(not always) indicate a packet loss. Output the RFC2833 digit?

The RTCP-version of this one is coming up soon. It's very nice to be able to get some information on the transmission quality such as number of lost packets and interarrival jitter.

I'm planning on doing some kind of 'monitor' for RTCP RRs and SRs and doing some statistical calculations on them and log this for all/some calls. I think this would be _very_ useful when hunting down echos and other network problems in general. Please note that Asterisk don't send any RTCP-packets, some RTP-stacks send them to us. At the moment we don't do anything about them, but there's alot of useful information in them.

I actually don't know if it would be useful for us to be sending SRs and RRs to our peers, will it take any kind of action depending on what we send? Can someone tell me if there's a RTP-stack that would change behaviour because of content in RTCP-packets?

The only(?) reason I see where it would be useful to generate RTCP-packets is when the remote peer is another Asterisk(or other RTP-stack) that can do something useful with the packets(for monitoring purposes or controlling bandwidth).

It would be cool to output all this information to monitor(generate fancy graphs?) call quality over time and identify individual hosts that have problems.

What say you?

//Filip

Current Rating: 0/10 (0 votes)

Comments (Click to post)

Similar Articles (Based on Title)

Vulnerability in Asterisk with verbose debugging - December 28, 2004
There have been some fixes to Asterisk to remove Format String Vulnerabilites

Lock Debugging Improvements - August 2, 2007
Russell has posted details of some changes he has put into place to allow for more simple locking debugging when in DEBUG_THREADS mode.

Convergence: IAX2 trunked (vs) IAX2+trunking (vs) RTP (vs) cRTP - October 31, 2004
Wasim has put up a comparisson of packet usages between diferrent methods of communication (trunking)

RTP timing problems patch - October 5, 2005
Carlos Antunes has posted details of a patch he has written which will generate timing independently of incoming packets.

Secure RTP - ready for testing - June 20, 2006
Olle has posted details of a testing branch for Secure RTP.

RTP packetization - August 18, 2006
Dan Austin has posted details of some packetization patches that need review.

RTP Packetization - September 1, 2006
Dan Austin has posted some details about a patch for RTP Packetization he is trying to complete (bugid 5162).

rtpBreak - detects, reconstructs and analyzes any RTP session - June 5, 2007
Michele Dallachiesa has posted details of an RTP analysis package.

AST-2009-004: Remote Crash Vulnerability in RTP stack - August 4, 2009
An attacker can cause Asterisk to crash remotely by sending malformed RTP text frames. While the attacker can cause Asterisk to crash, he cannot execute arbitrary remote code with this exploit.

Asterisk RTP Monitoring - September 25, 2009
Tzafrir has committed some documentation to his branch for RTP Monitoring.

What would you like to see more of? - October 8, 2004
I've readded the poll, because my coding was crap yesterday! Works now!

IAXclient-devel: Even more codecs - October 15, 2004
SteveK has now added changes to iaxclient libraries so that they support ulaw, speex, gsm and iLBC. (IAXclient libraries are used to create softphones)

The Daily Asterisk News

Similar Articles (Based on Title)