[asterisk-dev] Extensions to RTPAUDIOQOS for SIP/other
jtodd at loligo.com
Tue Apr 24 12:39:02 MST 2007
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 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?
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
More information about the asterisk-dev