FW: [Serusers] SER RTP QoS Monitoring

Mon Jan 30 12:56:05 CET 2006

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 at gmail.com] 
Sent: 30 January 2006 11:47
To: Aisling
Cc: John Todd; serusers at lists.iptel.org; clona at 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 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 < <mailto:ashling.odriscoll at cit.ie>
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 

-------------------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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060130/ffe25a7c/attachment.htm>