[asterisk-dev] Extensions to RTPAUDIOQOS for SIP/other channels

[Andrew Kohlsmith]

On Tuesday 24 April 2007 3:39 pm, John Todd wrote:
>    I'm not sure how that would work.  I can clearly understand how
> each RTP stream would have it's own statistics, but a "summary" at
> the end of a call which added up the various transferred legs would
> be difficult without extensive rework of the way RTCPAUDIOQOS is
> handled right now.  An array of some sort would be required, and then
> each RTP stream would probably need to have it's own set of values
> stored in the array, and then at the end of the call there would have
> to be some sort of summary math applied to those data.  While it
> would also probably give better visibility into the full life of the
> call and would be useful, I'm not sure the complexity would pay off
> (at least, not for me right now, but others might find it very
> useful.)  Especially when considering transfers into voicemail or
> into conference rooms which are not possible to measure, and bouncing
> in/out of such a non-RTP session would throw a monkey wrench into the
> stats for a particular leg unless those legs were simply "do not
> calculate" areas.

Actually I wish to concede this point; I'd love to have per-reinvite QOS data, 
with the end of the call giving the last one.  If I need overall stats I'd be 
storing this stuff in a DB or file somewhere and shuffling it off for 
post-processing.

I realized it would involve a rather involved rewrite of how things were 
currently done, but after reading your reply and thinking about it a little 
more, I don't think having Asterisk do the overall stat would be in any real 
way useful.

Most times the last reinvite would have the lengthiest part of the call 
anyway, and for most people that's all they care about.

-A.