This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

RTP packets are duplicated by UDP packets

0

Hi, folks! I've being analysed sample RTP-dump I've found on the Internet when I noticed some weird effect I can't really explain.

Some of RTP packets (or maybe all of them - I didn't check) are duplicated by UDP packets (they have identical payload) but with different srcIP and dstIP.

alt text

On the screenshot above 499th package is duplicated by 501th and 500th package is duplicated by 502th. And, as you can see, such duplicates are not classified by Wireshark as RTP-packets, but, as I mentioned, payload is identical.

It looks like destination machine (200.57.7.196) is forwarding such packets to another machine (200.57.7.199). But why? And when I open RTP streams analysis in Wireshark, it displays only 3 streams where 200.57.7.199 machine is absent.

So how do you explain it?

asked 16 Jul '16, 14:48

trixter's gravatar image

trixter
21●4●5●9
accept rate: 0%

edited 16 Jul '16, 14:49

2 Answers:

1

As you haven't provided a link to the capture you look at, I can only explain the generic part.

Imagine a setup where you have two VoIP phones in private IP subnets, accessing the internet via dumb NATs (i.e. no Application Layer Gateways), registered to the same VoIP service. In such case, the service cannot merely forward the SDPs between the phones, because the RTP destination addresses indicated in the SDPs are private ones and thus mutually unreachable. So what the service has to do is to use a techniques called "media proxying", "RTP forwarding" etc.: it uses a "controlled NAT" device, creates a pinhole between its two sockets on public IP addresses, and indicates these sockets as destinations for RTP, each of them to a different one of the phones, by replacing the original c= address in the SDPs forwarded from the other phone. So both phones thus send their RTP to the media proxy, which has to learn the actual source address of incoming RTP from a given phone (which is a socket on the public IP of the NAT) and use it as destination when sending to that phone the RTP coming from the other one.

The SSRC ID remains the same because the only part which the media proxy (controlled NAT) changes in the RTP streams is the eth:ip:udp header, the whole RTP payload remains unchanged.

Depending on where and how the capture has been made, it may contain both bi-directional RTP flows (between the media proxy and each phone), but only one signalling exchange. As RTP is hard to distinguish from any other UDP stream by its payload, Wireshark normally decides to dissect a UDP flow as an RTP one only if information from SDPs in the same capture (connection address, media stream port) matches the (IP address, UDP port) for source or destination of the UDP packets.

If there is no such SDP for one of the flows in your capture, Wireshark can only use the heuristic dissector to recognize that the UDP flow is actually an RTP one, and it may not always be able to do so.

It may even be that there is no standards-compliant signalling between the 200.57.7.196 and 200.57.7.199 because both of them may be controlled by the same controller so it only tells them to send RTP to each other using some proprietary control protocol running on another LAN so not captured.

If you need more, you'll have to provide a link to that capture.

answered 17 Jul '16, 00:12

sindy's gravatar image

sindy
6.0k●4●8●51
accept rate: 24%

Wow, great explanation, @sindy. And I guess, it's correct. You should post is as an answer and I will accept it. P.S. @Christian_R had attached the dump to the post, thanks.

(17 Jul '16, 01:48) trixter

OK, as @Christian_R has provided the link to the file, I can confirm that the stream between 200.57.7.196:40378 and 200.57.7.199:4800 is not established using any SDP present in the capture, and no other call control protocols but SIP and MGCP seem to be present in the capture (there is also H.225 but no H.245).

But what Wireshark version do you use? My 2.0.4 did recognize that stream as RTP without a hint.

(17 Jul '16, 01:52) sindy

And as for making it an Answer so that you could accept it: @Jaap's Answer was basically saying the same more briefly, so he deserves at least the "thumbs up" if you choose my Answer as the correct one.

(17 Jul '16, 02:01) sindy

I'm using 2.0.4 and I think I messed it up: I've seen checked 'rtps_udp' and misrecognized it as 'rtp_udp' option :( Now Wireshark detected 2 more conversations. Well, @Jaap, sorry for wrong comment, I thumbed you up at least.

(17 Jul '16, 03:02) trixter

@sindy, may I ask one more question? Which criteria should I use to find out true srcIP and dstIP and skip the proxy one? I'm developing own software for RTP analisys (and verify each step using Wireshark), so I need some correct algorithmic soluton for this specific case...

(17 Jul '16, 03:08) trixter

Leaving aside that this question is anything but a Wireshark one, it also cannot be answered unambiguously, because the right answer heavily depends on particular call scenario, capture point(s), and goal of the analysis.

Imagine the following logical arrangement:

          --SIP--- switch1 [---SIP--- switchN]* ---SIP--
        /             |                  |               \
phoneA {              |                  |                } phoneB
        \             V                  V               /
          --RTP---  mpxy1  [---RTP---  mpxyN]*  ---RTP--

(for example, each of the phones is connected to a different IPBX connected to a different operator - in such case, there are at least four voice switches between the phones) and imagine the possible different physical arrangements and capture points.

So the decision which RTP flow to analyze depends on which one(s) you have got in the capture and what you're after about the RTP. You may be looking for sources of jitter and packet loss, in that case you want to capture as many reincarnations of the RTP flow as you can to compare them to each other.

If you want to detect the extremities, you have to order the packets sharing the same SSRC and seqno by capture timestamps (provided that you've taken the capture at a single interface or that you're 150% sure about proper timestamp synchronisation between all the interfaces you have captured at). The source of the first one is closest to the real source which you can see, and the destination of the last one is closest to the real destination.

Plus as soon as one of the media proxies does more than just forward the RTP unchanged, you may lose the SSRC and RTP timestamps and you do lose the seqno. A typical case would be transcoding of DTMF between telephone-event codec in one branch and the basic PCMA or PCMU audio stream in the other one. In this case, a single telephone-event packet usually replaces several PCMx packets, so the transcoding media proxy must generate an independent sequence of seqno at the other side, although it may keep the SSRC value and RTP timestamps.

(17 Jul '16, 06:12) sindy
showing 5 of 6 show 1 more comments

1

Without knowing the specifics of the setup here, I image the following.

Your looking at various things. One is the signalling part, which Wireshark uses to start decoding these UDP packets as RTP (through the use of a so called conversation). The next is the involvement of a gateway, where and RTP endpoint is, possibly some processing is done (not in this case apparently) and a new RTP session originates. For this stream there's no signalling captured, therefore no 'conversation' defined, therefore no UDP packet interpretation as RTP. This could be done by setting an RTP_over_udp preference to also decode RTP outside conversations. Try that and see what happens.

answered 16 Jul '16, 15:45

Jaap's gravatar image

Jaap ♦
11.7k●16●101
accept rate: 14%

This option is enabled in my Wireshark (actually, I guess it's enabled by default, because I haven't enable it manually). Still we get what we get. Another question is: why the SSRC (sender identificator) is also the same in duplicated packets while the source IP address is diffirent? How can it be possible?

(16 Jul '16, 16:00) trixter

The SSRC is not the sender, it's the sync source. Since the gateway apparently doesn't change a thing (transparent) it only influences the underlying IP addresses, not the RTP information related to the sync source, which remains the same.

(17 Jul '16, 12:57) Jaap ♦