FW: [Serusers] SER RTP QoS Monitoring

Hi Jose, I looked at ethereal but I don’t think it’s possible to use that in real time i.e. you have to start the capture and when you think the call is over stop the capture and examine the results. I would like something in real-time…that makes me think tethereal perhaps might be an option…. Thanks, Aisling. -----Original Message----- From: Voipers Portugal [mailto:voipers@gmail.com] Sent: 30 January 2006 11:47 To: Aisling Cc: John Todd; serusers(a)lists.iptel.org; clona(a)cyberhouse.no Subject: Re: [Serusers] SER RTP QoS Monitoring 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(a)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(a)loligo.com] Sent: 29 January 2006 22:33 To: Aisling O'Driscoll; serusers(a)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 ashling.odriscoll(a)cit.ie> [060129 20:26]: -------------------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(a)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.