[Serusers] SER RTP QoS Monitoring

Voipers Portugal voipers at gmail.com
Mon Jan 30 12:46:47 CET 2006


Ethereal does that automatically, so I think you can start there. As for
RTPproxy, as far as I remember, it does not support RTCP (at least it didn´t
when I tested a few months ago).

Jose Simoes


On 1/30/06, Aisling <ashling.odriscoll at cit.ie> wrote:
>
>
> Hi,
>
> Thanks to John, Nils and Atle for the replies. So if I am to proceed
> with extracting QoS info from RTCP it is now my understanding that I
> would either have to have my QoS gathering application at:
>
> 1) the media proxy (used primarily for nat situations)
> 2) where the voice is going peer to peer, it would need to be placed at
> the end points. However what I'm wondering about here is would it be
> possible to have a QoS collector application running on another machine
> on the same network as the two endpoints (obviously presuming they're
> all on the same network) which could intercept the sender and receiver
> reports? And if so does anyone have any idea if there's another way to
> distinguish RTCP packets without knowing the IP address or port?
>
> Many thanks,
> Aisling.
>
> -----Original Message-----
> From: John Todd [mailto:jtodd at loligo.com]
> Sent: 29 January 2006 22:33
> To: Aisling O'Driscoll; serusers at lists.iptel.org
> Subject: Re: [Serusers] SER RTP QoS Monitoring
>
> Hello -
>   Your method #1 (RTCP) is the best solution, it would seem.  Method
> #2 (INFO) is sort-of supported in some devices, like the Cisco 79xx
> series with SIP software - they support insertion of some basic call
> element data into the BYE message.  Method #3 is complex, as it would
> require the SNMP collector to have full knowledge of all call states
> on the devices that were queried (though possibly this is not  more
> complex than the RTCP collection process, either.)  In any of these
> three cases, SER does not collect the call quality data - the
> endpoints or media proxies are the only places that see this data.
> If you run a mediaproxy in conjunction with SER, then it may be
> possible to collect and report on that data, but there are drawbacks
> to a design of that nature.
>
>   For the long term, I would suggest taking a look at this draft,
> which describes the use of RTCP-XR (or "vq-rtcpxr") as set of data to
> be transmitted via SIP messages between media-handling entities and
> other reporting systems:
>
>
> http://www.ietf.org/internet-drafts/draft-johnston-sipping-rtcp-summary-
> 08.txt
>
>   While we are still a while away from seeing vendor (or open source)
> implementations, this seems like a reasonable proposal.  It allows
> for SIP-based publication or subscription of call quality events by
> various network elements, and it will permit arbitrary querying of
> this data at any time interval (not just at the end of the call.)
>
> JT
>
>
>
> >Hi,
> >
> >I want to be able to extract QoS parameters such as jitter, delay and
> >packet loss from VoIP calls made using my SER(both peer to peer for
> >my public clients and also for clients where the voice will be routed
> >with mediaproxy). I would like to develop something as opposed to
> >purchasing a software package.
> >
> >>From searching the Internet the last few days I have seen that the
> >following options seem to be available:
> >
> >1) RTCP
> >RTCP stream will contain this information. The problem is that
> >sniffers cannot clearly distinguish RTCP packets from other UDP
> >packets unless something like an IP address or specific UDP port is
> >supplied. I had considered using TCPDUMP but then where do I position
> >this in the network when voice is going peer to peer between client
> >and I'm not sure how this can work to monitor all calls when I might
> >not be aware of the end user IP addresses.
> >
> >2) SIP INFO extension
> >This also seem to be an option but most off the shelf phones don't
> >seem to support this and this would required modification of a SIP ua.
> >
> >3) SNMP
> >I thought maybe SNMP might be an option but the SER snmp module no
> >longer exists...
> >
> >Does anyone have any comments on the above? Are the statements that I
> >made correct or can anyone think of other ways to monitor the voice
> >QoS? I am trying to understand how commercial applications have
> >accomplished this.
> >
> >Many thanks in advance for advice.
> >Aisling.
> >
> >>---- Original Message ----
> >>From: clona at cyberhouse.no
> >>To: ashling.odriscoll at cit.ie
> >>Subject: Re: [Serusers] Status of SER SNMP module
> >>Date: Sun, 29 Jan 2006 20:30:02 +0100
> >>
> >>>
> >>>Hi Aisling,
> >>>
> >>>The SNMP module is dead as a killed turtle :(
> >>>
> >>>-Atle
> >>>* Aisling O'Driscoll <ashling.odriscoll at cit.ie> [060129 20:26]:
> >>>>  Hello,
> >>>>
> >>>>  I'm just wondering what the current status of the SER SNMP module
> >>is?
> >>>>  Is it currently supported and is there somewhere I can find
> >>>>  documentation on it?
> >>>>
> >>>>  Many thanks,
> >  >>> Aisling.
> >
> >_______________________________________________
> >Serusers mailing list
> >serusers at lists.iptel.org
> >http://lists.iptel.org/mailman/listinfo/serusers
>
>
> -------------------Legal
> Disclaimer---------------------------------------
>
> The above electronic mail transmission is confidential and intended only
> for the person to whom it is addressed. Its contents may be protected by
> legal and/or professional privilege. Should it be received by you in
> error please contact the sender at the above quoted email address. Any
> unauthorised form of reproduction of this message is strictly
> prohibited. The Institute does not guarantee the security of any
> information electronically transmitted and is not liable if the
> information contained in this communication is not a proper and complete
> record of the message as transmitted by the sender nor for any delay in
> its receipt.
>
>
>
> -------------------Legal  Disclaimer---------------------------------------
>
> The above electronic mail transmission is confidential and intended only
> for the person to whom it is addressed. Its contents may be protected by
> legal and/or professional privilege. Should it be received by you in error
> please contact the sender at the above quoted email address. Any
> unauthorised form of reproduction of this message is strictly prohibited.
> The Institute does not guarantee the security of any information
> electronically transmitted and is not liable if the information contained in
> this communication is not a proper and complete record of the message as
> transmitted by the sender nor for any delay in its receipt.
>
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060130/0c19c6a9/attachment.htm>


More information about the sr-users mailing list