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@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.
-------------------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@iptel.org http://mail.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.
Hi Aisling, A few tought's, see inline :-)
- 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.
if you use rtpproxy, I think it also does rtpproxy for RTCP so, if you hack the rtpproxy code, you can proberbly get this info out.
- 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.
Hm, true, but FYI, I know Sipura can do some statistics in BYE messages. :)
- SNMP
I thought maybe SNMP might be an option but the SER snmp module no longer exists...
Hm, I might be wrong, but look at the fifo module from CVS head, and just introduce a new module, that get's the same info as the fifo module can get from Ser, and make a Snmp wrapper :) tough, I dont see the point, since SER does'nt do media.
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.
Good Luck!
-Atle
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.
-------------------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@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.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi,
the basic problem with your project is that someone needs to collect the QoS statistics (I assume that you are talking about voice quality and not about signaling). If the RTP is going end-to-end at least one of the devices has to this job. And then you are bound to whatever way this device offers to query/collect these stats. Only if you relay the RTP (over rtpproxy or mediaporxy) you would have a chance to create such stats independently from the end devices.
Greetings Nils
On Sunday 29 January 2006 21:14, Aisling O'Driscoll wrote:
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.
-------------------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@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.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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
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@loligo.com] Sent: 29 January 2006 22:33 To: Aisling O'Driscoll; serusers@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:
- 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
-------------------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.
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@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:
- the media proxy (used primarily for nat situations)
- 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@loligo.com] Sent: 29 January 2006 22:33 To: Aisling O'Driscoll; serusers@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:
- 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
-------------------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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Aisling - To address your points in order:
1) It would be possible to intercept the data (RTCP) QoS packets in a media proxy. Of course, if you want to check QoS on all your calls, then all media must pass through this media proxy. If you come up with some interesting way to perform this in any open-source manner, I'm sure the community at large would be very interested in hearing about it. I believe some Session Border Controllers have this functionality (perhaps those vendors can chime in via private mail to you if they have such functionality.)
2) Peer to Peer voice is more or less impossible to capture in real-world situations without a media proxy. I don't want to make this a rehash on why Ethernet sniffing is not viable as a production method, but a mesh of ethernet sniffers on a switched network would be exceedingly difficult, expensive, and sub-optimal. It would probably be cheaper to build your own SIP endpoint devices or software that did QoS reporting in a centralized way, or just force the use of a media proxy. If you are trying just to intercept a single conversation, then Ethereal will work fine if you have access to all of the traffic on an unswitched local segment.
JT
At 9:36 AM +0000 1/30/06, Aisling 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:
- the media proxy (used primarily for nat situations)
- 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@loligo.com] Sent: 29 January 2006 22:33 To: Aisling O'Driscoll; serusers@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:
- 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
-------------------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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
John Todd wrote:
Aisling - To address your points in order:
- It would be possible to intercept the data (RTCP) QoS packets in a
media proxy. Of course, if you want to check QoS on all your calls, then all media must pass through this media proxy. If you come up with some interesting way to perform this in any open-source manner, I'm sure the community at large would be very interested in hearing about it. I believe some Session Border Controllers have this functionality (perhaps those vendors can chime in via private mail to you if they have such functionality.)
Just to add a note on what we do at our company regarding QoS Monitoring.
99% of our users are given Sipura units with the "STATS in BYE" enabled which gives a nice little group of statistics in a header called "P-RTP-STAT". We then process those with the following code snippet in ser.cfg:
if (search("^P-RTP-STAT")){ xlog("L_ALERT", "STATS,%fu,%tu,%is,%ua,%{P-RTP-Stat}\n"); };
Once that is done a Perl script gathers all the data from the Syslog and dumps it nicely formated into a MySQL table. Our CRM software can read that table from the Subscribers Info screen. When a customer calls in, the Tech person can quickly click on a link to view the call quality of every single call this customer has made. It is quite handy and helps us pinpoint sources of call quality problems.
-
Aisling -
Aisling O'Driscoll
-
Andres -
Atle Samuelsen -
John Todd -
Nils Ohlmeier -
Voipers Portugal