[cisco-voip] Analyzing VoIP streams

[Mike Armstrong]

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