[asterisk-dev] Problems with RTCP

John Todd jtodd at digium.com
Wed Nov 5 20:16:41 CST 2008

On Nov 5, 2008, at 11:45 AM, John Lange wrote:

> I've been exploring the possibility of doing something useful with the
> RTCP statistics that Asterisk (and more specifically chan_sip)  
> generate
> and I've encountered a number of issues.
> After enabling the RTCP stats at the CLI as well as capturing them  
> from
> the RTPAUDIOQOS channel variable I noticed that the numbers it was
> reporting didn't make sense so I did a packet capture and analyzed it
> with Wireshark.
> In the scenario where we have:
> phone <-> asterisk <-> Cisco sip gateway (PRI)
> a call placed from the phone to the outside will generate 3 RTP
> streams.
> The first stream is the inbound call progress (the ringing sound)  
> coming
> from the PRI gateway and then, once the destination answers, a new  
> pair
> of RTP streams is created for in and outbound audio.
> The problem appears to be that only the statistics for the first  
> stream
> are kept and all other statistics are discarded.
> I can certainly understand how keeping statistics for mult-leg SIP  
> calls
> would be problematic so I'm wondering if it makes sense to keep all  
> the
> stats and present them all at the end as one big string? Alternatively
> they could all be totalled ?
> And a minor point, the values for ssrc in the RTPAUDIOQOS variable are
> presented as decimal values but they are actually a hex number in the
> packet streams. This makes comparing logs from Asterisk to packet
> captures in Wireshark very difficult.
> Before I do any digging around in the code I'm just wondering if  
> anyone
> has any comments on the current status of RTCP in Asterisk?
> Has it been improved much in 1.6 for example?
> John Lange
> www.johnlange.ca

As far as I know, it has not seen significant change in 1.6.

The complexities of RTP re-invites, transfers, etc. make it a  
difficult topic.  I don't even think the stats are correct in the  
first place, since I've _never_ been able to get remote side data, but  
I haven't exhaustively tested it.

The topic of a separate log called a "Call Quality Detail  
Record" (CQDR) has come up over the past 4 or more years, which has in  
various suggestions ways of managing these different problems that are  
disguised by the monolithic "Dial" command.  However, nobody has  
wanted to code for such a thing, so it remains hypothetical.  :-)



John Todd
jtodd at digium.com        +1-256-428-6083
Asterisk Open Source Community Director

More information about the asterisk-dev mailing list