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.t...
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:
- 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.
- 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.
- 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@cyberhouse.no To: ashling.odriscoll@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers