Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions

From: Magnus Westerlund <[email-masked]>
Date: Fri, 02 May 2003 13:13:41 +0200

Jonathan Rosenberg wrote:

>
> The idea is that the RTSP server implements STUN, yes. Muxing the RTP 
> and STUN is how you deal with symmetric RTP. How is that different 
> from having the RTSP server implement the new "fake RTP", and muxing 
> it with regular RTP?

The goal when I started to write down a specification for Symmetric RTP was not to use fake RTP in any sense. It is still RTP while there is a functionality listing in on the media port. This even don't need multiplexing as all packets can pass the listing function and then be forwarded if needed. In a streaming server there seem to be very little need to forward the RTP packet from the listing function. However other application scenarios may exist where the server really want to receive the media packets. 

One problem that the STUN solution might suffer from is that RTSP ALGs go in and change the destination header. This will not create a problem as long as it opens the necessary bind for the changed address. 

From a design philosophical point the STUN solution has its bad behavior in the multiplexing point while symmetric RTP has its in the layering. 

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: Thomas Zeng <[email-masked]>
Date: Fri, 2 May 2003 09:33:11 -0700

Magnus:

If true RTP packets are used as binding packets, as described in your email,
both Client and Server will take on the added burden of generating RTCP RRs
and SRs for them. Particularly, current RTSP client implementations only
generates RR, but in future, they would have to start sending SRs ! 

I like using a STUN like UDP packets as binding packets, and having RTSP
server distinguishing the two. 

One proposal I had last week was to use a simple UDP of 8 bytes as binding
packets, which is smaller than RTP/RTCP header (12 bytes), hence trivialize
the demuxing problem that people seem to be very afraid of.

Thanks,
- thomas

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Friday, May 02, 2003 4:14 AM
To: Jonathan Rosenberg
Cc: IETF MMUSIC WG
Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions

> from having the RTSP server implement the new "fake RTP", and muxing 

The goal when I started to write down a specification for Symmetric RTP was
not to use fake RTP in any sense. It is still RTP while there is a
functionality listing in on the media port. This even don't need
multiplexing as all packets can pass the listing function and then be
forwarded if needed. In a streaming server there seem to be very little need
to forward the RTP packet from the listing function. However other
application scenarios may exist where the server really want to receive the
media packets. 

One problem that the STUN solution might suffer from is that RTSP ALGs go in
and change the destination header. This will not create a problem as long as
it opens the necessary bind for the changed address. 

From a design philosophical point the STUN solution has its bad behavior in
the multiplexing point while symmetric RTP has its in the layering. 

Magnus Westerlund