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

[John Todd]

At 9:21 AM -0400 2007/4/24, Andrew Kohlsmith wrote:
>On Tuesday 24 April 2007 8:39 am, Olle E Johansson wrote:
>>  > So, two questions:
>>  >
>>  >  1) Does RTPAUDIOQOS currently change back to zero when transfers/
>>  > re-invites occur?  (I could test this myself, I know, but it would
>>  > require a lot more acrobatics and hopefully someone just knows.)
>>  >
>>  >  2) Would anyone object to the addition of the "far-end" IP address
>>  > for a given RTP stream being included in the RTCPAUDIOQOS string
>>  > somewhere, or available otherwise within the dialplan?  If there is
>>  > any consensus that this might be useful, we'll code up and/or pay
>>  > for the patch to be submitted to the community.  This seems like a
>>  > trivial patch.
>>
>>  I was working on a manager update with this information, propably #3
>>  in your list.
>
>In what sense, a manager event whenever a reinvite occurs, and which dumps the
>RTPAUDIOQOS information from the old peer, then zeroing the stats?
>
>It seems like we need two QOS stats... one which is reset on every reinvite,
>and one which is per-call...
>
>-A.

Olle -
   A manager command would be useful as well.  I'm a big believer in 
getting things into the Dialplan, too.  Any way a patch could be made 
for the two or three lines to create a variable while you're in there?

Andrew -
   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.

JT