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

From: [email-masked]
Date: Tue, 4 Mar 2003 14:31:00 +0100

Magnus,

Would not this look an awfull lot like STUN then ?

regards,

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

                                                                                                                                              
                                                          To:   Thomas Zeng <[email-masked]>                                            
                                                          cc:   "'Tom Marshall'" <[email-masked]>                                         
                                                           [email-masked]                                                                    
                                                           (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                         
               Magnus Westerlund                          Subject:    Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt              
               <[email-masked]                                                                                                
               .se>                                       Classification:                                                                     
                                                                                                                                              
               Sent by:                                                                                                                       
               [email-masked]                                                                                                          
                                                                                                                                              
               04/03/2003 10:34                                                                                                               

Hi Thomas and Tom,

I understand your performance considerations. I know we have discussed
this before on the teleconference. One reason raised for poor port
performance was the lack of optimized implementations. For example
linear search that of course give works performance as the number of
ports increase.

Should we fix this problem I think we should design something that are a
general mechanism that actually help us in other cases. Therefore my
suggestion is still to construct a RTP payload format and a RTCP packet
type that can carries challenge and responses containing security tags.

Thomas Zeng wrote:

>Magnus, Tom:
>
>Another reason that ports are precious resource on the server is that, a
>well designed
>streaming server may be able to scale up to 10000 simultaneous clients
>(which Microsoft's Windows Media server claims to support... I know
>Microsoft today doesn't use RTSP but it may in the future). If each has 6
>RTP tracks then there will not be enough ports to go around with Magnus
>proposal.
>

At least not with only a single IP address.

>
>Therefor I still think we must be prepared to resolve client SSRC conflict.
>Someone suggested that we can put in the "contributing SSRC" field the
>server's SSRC for that session. The combination of client SSRC and server
>SSRC in the binding RTP packets would be certainly possible to ensure
>uniqueness (since the server can choose its SSRC with no collision).
>
>What do people think?
>
I think this last proposal is a bad idea. It may very well have
implications on the future extensions that we deploy. It also changes
the meaning of the SSRC and CSRC field to not be the standardized ones.
The general problem is that RTP was not designed to have multiple
sessions on the same port. This is simple something the manufacturers of
streaming severs has done to solve an operations system performance
problem.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 04 Mar 2003 15:05:17 +0100

Hi, Phillipe,

My proposal:

>Would not this look an awfull lot like STUN then ?
In some sense yes, but mostly no. The goal of this mechanism is to 
identify the intention of sending media and authorizing it. What it 
shares with STUN is the possibility to use it for NAT traversal.

The comparison with STUN would give the following advantages:
- Being integrated into RTP/RTCP it will not have the multiplexing 
problems of STUN.
- It can be used for the general DESTINATION problem of RTSP.

Disadvantage:
- Not being general, only useful with RTP. To solve the multiplexing the 
solution needs to be part of the media protocol. Problem for any 
solution that handles symmetric NAT. 

What this solution will not provide that STUN has is:
- Mechanism to learn the external mapping.
- Mechanism to detect what type of NAT your behind.
- Mechanism to determine the NAT mapping time-out.

I hope you  see the differences that it is not awful lot like STUN. It is in fact another way of traversing NATs which has other advantages. 

Regards

Magnus Westerlund