[asterisk-dev] Problems with RTCP

[Atis Lezdins]

On Thu, Nov 6, 2008 at 4:16 AM, John Todd <jtodd at digium.com> wrote:
>
> 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.  :-)
>
> http://www.google.com/search?hl=en&q=site%3Alists.digium.com+asterisk+cqdr&btnG=Search
>

Hello,

I played with RTCP stats a while ago, and as i remember enabling "rtcp
stats" and "rtcp debug" helped to get quite detailed info in log,
however analyzing it has been hardest part, as it's reporting only SIP
channel id, so i had to enable also SIP debug to see which stats are
referring to which calls. In total i made few scripts with complex
grepping rules to get "Packets lost" data for specific IP's.

I wonder would it be possible to append RTCP responses to CDR, as Dial
is producing separate CDRs for each channel involved. So each channel
could have their own RTCP stats.

Regards,
Atis

-- 
Atis Lezdins,
VoIP Project Manager / Developer,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835