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

From: [email-masked]
Date: Wed, 30 Apr 2003 10:22:35 +0200

all,

This seems to be getting pretty complicated and tricky....

Actually in the ligth of this discussion the usage of STUN looks
so much more straigthforward no ?

regards

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

                                                                                                                                       
                                                   To:   "'Magnus Westerlund'" <[email-masked]>                     
                                                    Aaron Colwell <[email-masked]>                                                  
                                                    IETF MMUSIC WG <[email-masked]>                                                   
                                                   cc:   (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                    
               Thomas Zeng                         Subject:    RE: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions                
               <[email-masked]>                                                                                                  
                                                   Classification:                                                                     
               Sent by:                                                                                                                
               [email-masked]                                                                                                   
                                                                                                                                       
               29/04/2003 23:24                                                                                                        

>  -----Original Message-----
> From:            Magnus Westerlund [mailto:[email-masked]]
>
> Sent:            Tuesday, April 29, 2003 11:04 AM
> To:        Aaron Colwell; IETF MMUSIC WG
> Subject:         Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions
>
> Hi Aaron,
>
> See my answer below inline.
>
> Aaron Colwell wrote:
>
>  >I have a few questions about section 3.2.3 list item 8. It says
>  >"For RTCP it starts transmitting RTCP packets according to the rules."
>  >
>  >1. Does this mean that it starts sending  compound SR and SDES packets?
>  >
>
> Depends on the RTP session state. Unless the server has not sent any RTP
> packets yet it must send RR and SDES. If it has sent RTP packets then it
> need to send SR and SDES.
>
>  >2. Is the client supposed to created it's own CNAME for this stream of
>  >   packets or does the CNAME need to be sent from the server to the
> client?
>  >
> The client must set a CNAME of its own. That it must always do when
> sending RTCP in a RTP session.
>
>  >3. Should the client and server both send RR info to eachother about the
>  >   RTP packets they are sending?
>  >
>
> Yes, It should report on these packets.
>
>  >4. Are there any requirements for the RTP packet timestamps other than
>  >   being monotonically increasing?
>  >
>
> No, I need to think over what would be the best strategy here. One would
> be to use the RTP send time as TS basis.
             [Thomas Zeng]  This is the reason that makes it hard to treat
ip/port binding packets as RTP packets. These binding packets are not really
media packets, yet according to RTP rules, they would have to be accounted
for in RR and SRs. All of a sudden RTSP clients would now need to send SRs
back to  RTSP servers. That probably won't please implementors of thin RTSP
clients.

> In general I think we need to further look over this section. Is it a
> good thing to use PT=0, i.e. PCM audio with no samples for these
> packets? Please comment.
             [Thomas Zeng]  How about not treating binding packets as RTP packets
at all? My suggestion would be to use a simple UDP packet that contains an
SSRC (the server SSRC as indicated in SETUP response, so as to  make it
possible to uniquely identify RTP session in the event server is sending RTP
packets from a shared UDP port in order to conserve server resources -- a
common practice among implementors of large scale servers) ? If you want to
indicate that re-transmission of binding packets are taking place, we can
put a 4- byte counter in this binding packets as well. That is, the first
binding packet is try number 1, the second is try number 2, etc...  The fact
that this binding packet is smaller than RTP / RTCP header makes it real
easy for the server to distinguish between RTP and RTCP packets and the port
binding packets. Any other packets would be disgarded. A binding packet with
incorrect SSRC or counter are also discarded.

> Best Regards
>
> 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
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

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

---

From: Tom Marshall <[email-masked]>
Date: Wed, 30 Apr 2003 07:43:43 -0700

> This seems to be getting pretty complicated and tricky....

Unfortunately, that is the nature of NAT.

> so much more straigthforward no ?

Well, the case of a STUN server that is a third party to the client and
server is quite straightforward.  But that doesn't work with 5-tuple NAT
setups, so we have the RTP/STUN multiplexing case.  And that, really, is no
more or less complicated than "symmetric rtp".  They are mostly equivalent
solutions.  It only looks less complicated at this point in time because the
format for STUN packets has already been agreed upon, and we are still
looking at the format for the "symmetric rtp" packets.

-- 
Did you ever notice that fat chance and slim chance mean the same thing?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Apr 2003 11:00:58 -0400

Tom Marshall wrote:

> 
>> Actually in the ligth of this discussion the usage of STUN looks so
>> much more straigthforward no ?

I was thinking the same thing.

> 
> 
> Well, the case of a STUN server that is a third party to the client
> and server is quite straightforward.  But that doesn't work with
> 5-tuple NAT setups, so we have the RTP/STUN multiplexing case.  And
> that, really, is no more or less complicated than "symmetric rtp".
> They are mostly equivalent solutions.  It only looks less complicated
> at this point in time because the format for STUN packets has already
> been agreed upon, and we are still looking at the format for the
> "symmetric rtp" packets.

Its an issue of - why are you inventing yet another thing when we 
already have something on the table?

-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: Wed, 30 Apr 2003 17:51:50 +0200

Hi Jonathan,

> already have something on the table?

Well, I think I might have to crawl to the cross. I don't like the 
multiplexing of RTP & RTCP with STUN. However it seems that symmetric 
RTP will probably be only slightly less evil. It is the RTP binding part 
that I am worried over. If we had a binding payload with a static PT I 
would not hesitate a minute. However without it the implications is a 
bit more problematic. RTCP is obviously not a problem as the binding 
RTCP packets are normal and can be forwarded to the normal processing 
without any consideration.

However one issue that remains is that a server will most likely need to 
have announced ports for RTP and RTCP which can't be changed and for 
which all RTP/RTCP and STUN traffic is directed too. From minimizing 
setup time a STUN solution for symmetric NATs should probably get the 
SDP, Do all STUN request in parallel for the media streams to the in SDP 
announce ports. Then do SETUP request with the learned destination 
addresses. The other alternative sequence where a client learns the 
servers STUN port numbers through RTSP would require two SETUP requests. 
Doesn't this make the server vulnerable?

Best Regards

Magnus Westerlund

---

From: Aaron Colwell <[email-masked]>
Date: Wed, 30 Apr 2003 09:00:05 -0700 (PDT)

In my opinion requiring an implementation to use STUN to do this is a
pretty large requirement. It means the client will have to have a TLS
implementation right? The cost in code space or CPU usage of the TLS
implementation may be too high for some embedded applications like 3GPP
devices. I think demultiplexing the STUN and RTP/RTCP messages could get
tricky. The STUN solution also won't work behind a Symmetric NAT unless
the server implements STUN as well. I just feel that the use of STUN puts
too many requirements on the client and server.

I agree with Thomas though that by making these binding packets RTP data
packets, the client and server end up having to do much more RTCP protocol
then we really need. We really just need a packet that looks like an RTP
packet like Tom Marshall said. We could just get one of the reserved
payload types assigned for binding packets and specify that these packets
do not require the normal RTCP chat associated with a data stream. Old
implementations will keep state for these packets and send RTCP chat for
the data, but newer impelementations will know that they don't have to
care about these packets.

What do people think?

Aaron

---

From: Tom Marshall <[email-masked]>
Date: Wed, 30 Apr 2003 08:58:41 -0700

> already have something on the table?

I can think of two reasons:

1. The technique is already in use, and has been proven successful.  We are
   trying to document that technique.

2. It has advantages over STUN.  It is more successful than nonmultiplexed
   STUN (eg. with 5-tuple NATs) and it does not require any protocol
   multiplexing to achieve maximum usefulness (it's a cleaner solution).

I can see where STUN may have uses for protocols other than RTP, and that is
fine.  But to imply that STUN is the one grand solution and we shouldn't
pursue symmetric rtp is, in my opinion, a mistake.

-- 
There is nothing new under the sun, but there are lots of old things we
don't know yet.
        -- Ambrose Bierce

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Apr 2003 16:43:21 -0400

I think there are some misconceptions here. More inline.

Aaron Colwell wrote:
> implementation right?

No. In the usage of STUN here, which is peer-to-peer, you would not use 
TLS. You would not need most of the features of STUN. Just the HMAC 
authentication, and the baseline case of sending a response to the place 
the request came from (i.e., no change flags, no response address, 
etc.). Really just a "ping" plus an HMAC over the address that gets 
returned.

  The cost in code space or CPU usage of the TLS
> too many requirements on the client and server.

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?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Apr 2003 16:46:46 -0400

>    trying to document that technique.

IETF proposed standards are not about documenting existing technique. 
They are about proposing the right solution for all to implement.

>    multiplexing to achieve maximum usefulness (it's a cleaner solution).

The only argument you are making here is that multiplexing is ugly. To 
that I agree. But, if you want these fake RTP packets to not affect 
RTCP, you are already basically saying that you are multiplexing a 
non-RTP protocol on the RTP port. So I dont see the difference really.

> pursue symmetric rtp is, in my opinion, a mistake.

Well, as is pointed out in my ICE proposal:
http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-00.txt

The general approach solves a ton more cases than symmetric RTP alone 
will. If you ever think that you will want RTSP in peer-to-peer cases, 
symmetric RTP isnt going to cut it.

-Jonathan R.