Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm testing a VoIP system based on OpenSIPS. It has no RTPproxy, so calls do not pass through OpenSIPS.

I tried to make a call between two smartphones, and it succeeded. I also turned on Wireshark, and got this result:

enter image description here

Does that mean that the voice call from the first phone to the second phone went through the first RTP stream, and the voice call from the second phone to the first phone went through the second RTP stream?

Why couldn't it just use one RTP stream? It could just go back and forth.

share|improve this question

If you really want to know more about the design of RTP, I recommend reading the RTP book by Perkins and the RTP FAQ.

A few comments: RTP has been designed with much flexibility in mind and caters for many use cases e.g. multicast. In your example the RTP source and destination ports are the same, this is often not the case, read the FAQ for an explanation.

Note that even if a participant sends both audio and video, these are sent over separate RTP sessions (again read the FAQ).

share|improve this answer
Thanks, I've read the FAQ. There's something that I don't understand. If one conversation use two RTP sessions/streams, would that mean double bandwidth usage? For example, if the conversation uses G.711 (64 kbps), would the bandwidth usage become 128 kbps (exclude overhead)? – pepito May 24 '12 at 4:14

RTP stream is unidirectional, and there is no back talking. The stream in the opposite direction usually takes the same UDP port numbers, but in fact these streams are treated independently by endpoint software

share|improve this answer
Thanks. I've already figured that out. – pepito Jun 24 '12 at 2:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .