Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-users: RE: [Ethereal-users] RTP & UDP

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Francisco Alcoba (TS/EEM)" <francisco.alcoba@xxxxxxxxxxxx>
Date: Wed, 30 Mar 2005 11:20:30 +0200
Hi,

> I have 2 traces I have saved, one includes a phone to system 
> connection 
> and the second is ip Phone to IP phone connection.  The first 
> stream is 
> as I expected, with H.225 used for call setup and the voice 
> wrapped in 
> RTP. 
> 
> The second stream, does not appear to use RTP??? All I see are UDP 
> packets with 32 byte payloads, but no distinguishing wrappers for the 
> data. 
> 
> The system is an Avaya IP Office with an Avaya VoIP phone on 
> this end.  
> Depending on the call the other end is terminated either in the same  
> type IP Phone or a corresponding digital phone.  I would 
> expect the IP 
> Office to decode the IP for a connection to the digital phone and the 
> addressing seems to confirm this. 
> 
> Has anyone else seem this or am I missing something as I 
> capture packets?

I don't fully understand the traffic case. You might have:

 - one call that sends the signalling through the system, and the RTP directly
   between the phones; in that case, if they are in different captures, there is 
   no way Ethereal can now by itself the traffic between the phones is RTP

 - two different calls, and the one between phones does not show signalling or RTP at all

 - two different calls, and the one between phones does show signalling, but no RTP

If your situation is the second one, I'd look for packets missing in the capture,
proprietary protocols -i.e. not H.225, SIP, etc.- being used to set up the call,
encryption, etc.

If it is the first, you can try by selecting one UDP packet and on the context menu
selection "Decode As", so you can tell Ethereal to decode the flow as RTP -and see
whether the decode makes sense-. If both traces are different but correspond to the
same call, merging them might help also -so that Ethereal can see the RTP flow description
in the signalling packets, and understand the UDP packets are RTP-.

If it is the third, the problem might be with Ethereal not recognizing the flow description
inside the signalling. 

In any case, it might help if you can produce the traces; as a general rule, you need
to remember but RTP uses dynamic ports, so Ethereal needs some way to find out the
packets are RTP, or it will show them as UDP.

Regards,

  Francisco