[cisco-voip] Analyzing VoIP streams

[Paul Long]

Mike,

RTP uses dynamic ports which are in the range 1024-65535, so 0 is
straight out. Must have been a bug because OLCAck should never specify
port 0 (http://www.iana.org/assignments/port-numbers). Seems like I've
read that Cisco uses 16384-32768 for RTP, so if it's ever outside that
range, something's really screwed up.

Yeah, Ethereal has always been pretty slick but has really improved in
the last couple of years. One of the authors contacted me recently
looking for more protocols to support. Apparently they're having a hard
time finding protocols that Ethereal doesn't already support.

Paul

-----Original Message-----
From: Mike Armstrong [mailto:mfa at crec.ifas.ufl.edu] 
Sent: Tuesday, February 22, 2005 11:38 AM
To: cisco-voip at puck.nether.net; Paul Long
Subject: RE: [cisco-voip] Analyzing VoIP streams

It turns out you hit the nail on the head with the first stroke when you

said "...make sure the stream is being sent to where you expect".  In
the 
problem at hand, Unity is ACKing the CCM's OpenReceiveChannel request
and 
telling it to use Port 0.  That gets passed to the IP Phone, so the UDP 
stream hits Unity on Port 0, where it's apparently ignored.  After 5
seconds 
of this, Unity interrupts and eventually terminates the call.  The
problem I 
had (until I spent some quality time with TAC) was that I didn't know
what 
the correct port should be.  I was pretty sure Port 0 wasn't right, but
just 
sloughed off the entire trace to TAC, where my suspicions were
eventually 
confirmed.  Now I are an expert in this tiny bit of CCM-IP Phone-Unity 
protocol, but I'll be back in stupid mode for the next problem.  I 
appreciate the Ethereal/RTP tips.  The more I use Ethereal, the more I 
appreciate it.

mike

> Date: Tue, 22 Feb 2005 10:57:22 -0600
> From: "Paul Long" <plong at metreos.com>
> Subject: RE: [cisco-voip] Analyzing VoIP streams
> To: <cisco-voip at puck.nether.net>
> Message-ID:
> <6EE053013F00084096AF0F02CFDB88B804CFBD at securemail.metreos.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Mike,
>
> The streams initially show up in Ethereal as UDP packets. So to start
> with, you need to right click on a packet from each stream and select
> "Decode As..." from the menu and then RTP and OK. That'll give you a
bit
> more info.
>
> The most interesting fields are
> - the UDP destination port and IP destination address to make sure the
> stream is being sent to where you expect, and
> - the RTP payload type to make sure the expected codec is being sent.
>
> The RTP marker bit should be set at the beginning of a "talk spurt,"
but
> that's not interesting at all and I know of nobody that makes use of
it.
> Other boring RTP fields: version (should always be 2), padding
> (typically 0 for audio codecs unless the packets are really screwed
up),
> extension (for proprietary header extensions, which I've never seen
> anybody use), contributing source identifiers, synchronization source
> identifier (unless you're into some complex conferencing apps).
>
> You could make sure the RTP timestamps increase in a regular fashion
> (the actual scheme is specific to the codec profile). The RTP sequence
> numbers should increase monotonically.
>
> Oh yeah, and there is this thing called the payload. :-) It is of
course
> codec specific. G.711 (a sample-based codec) should have lots of these
> in it: 0xff, 0xfe, 0x7f, and 0x7e. The payloads of frame-based codecs,
> such as G.729 and G.723.1, are more structured and variable.
>
> What else do you want to know?
>
> Paul
>
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Mike
Armstrong
> Sent: Tuesday, February 22, 2005 7:08 AM
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] Analyzing VoIP streams
>
> Can anyone recommend any documentation describing VoIP streams and how
> to
> analyze them?  I've captured an IP Phone<-> Unity stream from a failed
> call
> (using Ethereal), can kind of guess what's going on, but need more
> detailed
> info to figure out what's not right.
>
> Mike Armstrong
> UF/IFAS CREC
> Lake Alfred, FL