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

[John Todd]

At 8:10 AM +0200 2007/4/26, Olle E Johansson wrote:
>>25 apr 2007 kl. 23.02 skrev Kristian Kielhofner:
>>On 4/24/07, John Todd <jtodd at loligo.com> wrote:
>>>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?
>>>
>>
>>  I like the idea but I'd like to keep it in the dialplan.
>>
>>  For now just something that could log the IPs of the actual RTP
>>endpoints in a standard "SIP trapezoid" type call setup would be a
>>great start.  Perhaps we need a new variable for this - ${RTPIP} or
>>similar?
>It should be part of the existing SIP functions, like SIPCHANNEL
>or maybe an extension to the core CHANNEL function.
>/O


I'm torn if this should be a channel-specific item, or if it should 
be left in some type of RTP-based value in the core CHANNEL 
functions.  I'm thinking the latter, since H323, Gtalk/Jingle, and 
SIP all use RTP and could benefit if the value was not specific to 
each channel type.

At this point, I'd be happy if the value was just added to the end of 
the RTPAUDIOQOS blob like this, which seems pretty trivial to 
implement:

ssrc=946918584;themssrc=3607239124;lp=7;rxjitter=0.005826;rxcount=1253;txjitter=0.000000;txcount=1264;rlp=0;rtt=0.000000;rtpip=11.22.33.44


JT