Subject: [MMUSIC] What is symmetric RTP?

From: Tom Marshall <[email-masked]>
Date: Wed, 19 Mar 2003 10:54:29 -0800

I have been doing a bit of digging, trying to find an exact definition of
"Symmetric RTP" -- that is, what exactly is it, and how it should be used. 
Ironically, the biggest reference to Symmetric RTP (according to google)
seems to be the recent discussions on this mailing list.

The draft draft-ietf-mmusic-sdp-comedia-04.txt was mentioned at one point. 
It has now expired.  I found a cached copy and read it.  It does seem to
provide some brief explanation of how to do Symmetric RTP, but it does not
look detailed enough.  Section 8.5 is titled "Example: "Bidirectional" RTP
and RTCP" and it says only "... immediately sends RTP from ..." and "...
immediately sends RTCP from ..." with no explanation of the expected packet
contents.

I would like to see Symmetric RTP defined more precisely, both for our own
use and for comedia.  What do others think?  Would someone like to clarify
usage, provide examples, start a draft, etc?

-- 
Harrison's Postulate:
        For every action, there is an equal and opposite criticism.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Mar 2003 05:46:22 +0100

Hi Tom,

I agree that the term symmetric RTP is really not defined in any 
document. I have one view of this that is a result of following 
discussions around NATs in AVT, SIPPING, and MMUSIC. In my view people 
often mean two things when they are talking about symmetric RTP.

1. The sending and receiving of RTP from the same port. This was the 
case in the ancient days, :-),  of multicast usage and RAT . However 
then the SIP and some other people come around and distorted this view 
with not using the same port for receiving and sending.
2. The usage of a received message to determine the destination address. 
This is I think the main idea when performing NAT traversal. Of course 1 
must be used to make it work, however this is simple. It is the second 
usage that has some problems.

One possible place to better define symmetric RTP could be the RTSP NAT 
draft.

Best Regards

Magnus 

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 26 Mar 2003 16:57:41 +0100

Hi,

I would like to clarify some things in my previous mail.

> with not using the same port for receiving and sending. 

Bad choice of language here. I don't want to blame the SIP people for 
the change. RTP has the flexibility to be used with different ports at 
different end points and sending from another port then receiving. It i 
s after all a matter of being able to signal.

>
> 2. The usage of a received message to determine the destination 
> address. This is I think the main idea when performing NAT traversal. 
> Of course 1 must be used to make it work, however this is simple. It 
> is the second usage that has some problems.

>
> One possible place to better define symmetric RTP could be the RTSP 
> NAT draft.

After some thought and discussion, I don't think the RTSP NAT draft is 
the right place anymore. If we would do a specification of what 
symmetric RTP is, it should be a stand alone document that can be 
referenced both by SIP and RTSP and any other signaling that has use of 
the functionality.

Best Regards

Magnus Westerlund

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Mar 2003 11:19:34 -0500

> s after all a matter of being able to signal.

Well, really the issue is that usage of RTP with unicast has been a 
source of constant confusion even to this day.

> referenced both by SIP and RTSP and any other signaling that has use of 

THe reason that this went into comedia is that, once you do this, UDP 
effectively looks "connection oriented". THe same issues exist as they 
do for TCP - who is active, who is passive? How is it negotiated? Thats 
what comedia does.

That said, I still believe that it is desirable to align RTSP NAT 
solutions with SIP. Symmetric RTP is nice, but it is not as general as 
the ICE-based approach I have proposed. There are many topologies where 
symmetric RTP will not work. Any topology where the server itself is 
behind a NAT. A good example is two enterprises. Lets say there is a 
manufacturer that makes widgets. They have customers in lots of 
enterprises. They want to run an RTSP server inside their enterprise, so 
users can connect and see videos providing customer support. If the 
customer enterprises are natted, and so is the widget manufacturer, 
symmetric RTP will not help. ICE would figure out the best approach. The 
only case in which ICE requires more than one exchange to work in this 
case is when both NATs are full-cone. In such a case, you can eliminate 
the second ICE exchange if you use a TURN relay.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Mar 2003 08:31:03 +0100

Hi Jonathan,

See below:

Jonathan Rosenberg wrote:

>> After some thought and discussion, I don't think the RTSP NAT draft 
>> is the right place anymore. If we would do a specification of what 
>> referenced both by SIP and RTSP and any other signaling that has use 
>> of the functionality.
>
>
> do for TCP - who is active, who is passive? How is it negotiated? 
> Thats what comedia does.
>
> the ICE-based approach I have proposed. There are many topologies 
> where symmetric RTP will not work. Any topology where the server 
> itself is behind a NAT. A good example is two enterprises. Lets say 
> there is a manufacturer that makes widgets. They have customers in 
> lots of enterprises. They want to run an RTSP server inside their 
> enterprise, so users can connect and see videos providing customer 
> support. If the customer enterprises are natted, and so is the widget 
> manufacturer, symmetric RTP will not help. ICE would figure out the 
> best approach. The only case in which ICE requires more than one 
> exchange to work in this case is when both NATs are full-cone. In such 
> a case, you can eliminate the second ICE exchange if you use a TURN 
> relay.
>
> -Jonathan R.
>
I can understand your desire to align RTSP and SIP. However when it 
comes to usage of ICE it definitely gets problematic. First RTSP does 
not have the SETUP exchange in place to accommodate something like ICE 
need for one or more exchange with parameters both for the STUN server 
and the given addresses. I don't say it is impossible however more work 
will be needed to look at how it could be included. Then one will see 
how many modifications it would requires. In the end it might be simpler 
to take on the SIP session initiation and only keep RTSP's media 
control.  However this is a radical proposal that would significantly 
change the protocol.

One question I would like to know is how big the envisioned problem will 
be with servers that reside in NATed networks. I can understand that SIP 
must consider all cases as it set up communication between users which 
are more likely to have NATed addresses. However looking at RTSP which 
has a clear client to server structure, much like HTTP. If you move a 
server to a NATed address you will also have problem setting up the TCP 
connection. You simple will require a proxy between the address domains 
to be able to communicate. Are there many that deploy HTTP servers in 
private address spaces and actually intend them to be used by other 
address domains? So far my view has been that as this is server, the 
server owner can ensure that the server has an IP address that makes it 
reachable by the intended clients. So in your widget manufacturer 
example above, why does not he deploy the server in the public IP space. 
I would assume that he has HTTP server that are also reachable. If you 
don't share my opinion on this please speak up and give some motivation 
why this is a useful example. 

Regards

Magnus Westerlund

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Mar 2003 09:47:13 -0500

> control.  However this is a radical proposal that would significantly 

Well, I suspect it would not change the protocol so much as only use a 
subset - the parts for control.

Regarding having RTSP itself support an offer/answer exchange with 
SETUP, generally only one exchange would be needed. So, its just an 
issue of putting more than one address in the SETUP.

> why this is a useful example.

I think that you are making a fair point; if the widget manufacturer 
meant for this server to be reachable, they need to give it a public 
address.

I think the cases where this might not be true is where "server" becomes 
more loosely defined. You have in mind a big server meant for consumer 
streaming media applications. However, I can imagine using RTSP to do 
things like retrieve voicemails, and even control streams shared 
directly between two users (for example, one user calling another with 
sip and letting the called party hear an mp3 that the caller has on 
their PC). All of these are, IMHO, good uses for RTSP, and none of them 
will work with the symmetric-RTP only approach you are advocating.

So - are these places you want RTSP to work?

-Jonathan R.