Subject: RE: [MMUSIC] RTSP 2.0: Use of independent TCP

From: "Xavier Marjou" <[email-masked]>
Date: Fri, 08 Dec 2006 12:27:11 +0100

> I think you misunderstood my meaning. For example, a media end host is 
> behind a symmetric NAT and a media server is in the open. From media 
> server's perspective, the public IP address of RTSP client may be 
> 202.102.11.1, but the public IP address of independent TCP (RTP 
> receiver) may be 202.102.22.2, although they both originate from the 
> same end. But media server can't determine that these two connection 
> originate from the same end by their public IP address, so it will 
> reject the connect request of independent TCP.
> Can you tell me how to solve this problem?

I think that using the SDP offer/answer to negotiate as a whole an RTSP 
stream and other media streams would merit discussion, as it could help NAT 
traversal. Maybe this could be an interesting use-case to be developped in 
the context of sip-rtsp convergence drafts.

Cheers,
Xavier

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 08 Dec 2006 13:32:33 +0100

Hi Xavier,

Yes, there are some interest of taking the step towards using SIP/SDP 
offer/answer to replace the RTSP SETUP. Especially to support new 
deployment scenarios for RTSP.

However in the work of updating RFC 2326 it is far from obvious that we 
should take this step. There is clearly a large deployed base of RTSP 
1.0 which can quite easy transition to support an RTSP 2.0 with SETUP 
still there. Removing SETUP introducing SIP would be a large unnecessary 
cost for the current deployments. And NAT traversal is needed also for 
these cases.

In my view we should finish up RTSP 2.0 as currently outlined. Keeping 
the changes to minimal. Fixing the issues and providing a few features 
that sell this upgrade by improved performance. As a completely separate 
effort we can discuss the use of SIP/SDP offer/answer for session 
establishment.

Cheers

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 8 Dec 2006 16:40:16 -0800

>Yes, there are some interest of taking the step towards using 
>SIP/SDP offer/answer to replace the RTSP SETUP. Especially to 
>support new deployment scenarios for RTSP.
>
>However in the work of updating RFC 2326 it is far from obvious that 
>we should take this step. There is clearly a large deployed base of 
>RTSP 1.0 which can quite easy transition to support an RTSP 2.0 with 
>SETUP still there. Removing SETUP introducing SIP would be a large 
>unnecessary cost for the current deployments. And NAT traversal is 
>needed also for these cases.

This brings up the question: Is there anything 'ICE like' that can be 
done to help RTSP clients (or even RTSP servers) that are behind 
NATs?  When I asked Jonathan about this during his ICE tutorial in 
San Diego, he noted that ICE is currently SIP-specific, but that it 
could, in principle, be adapted (as a new design) for other 
protocols.  He also mentioned that you (Magnus) had done some initial 
work a while back on looking at ICE-for-RTSP, but that this work was 
not currently up-to-date.

My question now (as I'm still not up to speed on ICE, although 
Jonathan's turorial helped a lot): Which of the following statements 
is true?
1/ ICE-for-RTSP could, in principle, be designed to work for RTSP 1.0 
(and RTSP 2.0), with no changes to either.
2/ ICE-for-RTSP could, in principle, be designed to work for RTSP 
2.0, with no changes (but not for RTSP 1.0).
3/ ICE-for-RTSP could, in principle, be designed to work for RTSP 
2.0, but requiring some small additional changes to RTSP 2.0.
4/ ICE-for-RTSP could not be designed to work for RTSP 2.0 without 
significant changes, so therefore it would make more sense to wait 
for a future "RTSP 3.0" (using SIP offer/answer), so that we could 
use more of the existing ICE-for-SIP work.
???

	Ross.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Dec 2006 14:07:06 +0100

Ross Finlayson skrev:
> done to help RTSP clients (or even RTSP servers) that are behind NATs?  
> When I asked Jonathan about this during his ICE tutorial in San Diego, 
> he noted that ICE is currently SIP-specific, but that it could, in 
> principle, be adapted (as a new design) for other protocols.  He also 
> mentioned that you (Magnus) had done some initial work a while back on 
> looking at ICE-for-RTSP, but that this work was not currently up-to-date.
> 
> Jonathan's turorial helped a lot): Which of the following statements is 
> true?

No, as RTSP 1.0 doesn't allow extension to the transport header this 
can't be done in my opinion.

> 2/ ICE-for-RTSP could, in principle, be designed to work for RTSP 2.0, 
> with no changes (but not for RTSP 1.0).

If you with no changes to RTSP 2.0 means no further changes to the base 
spec. Then I would say yes. The plan is to provide ICE for RTSP in an 
extension package that is fully compatible with the base spec. And I do 
believe that is the truth.

> 3/ ICE-for-RTSP could, in principle, be designed to work for RTSP 2.0, 
> but requiring some small additional changes to RTSP 2.0.
> significant changes, so therefore it would make more sense to wait for a 
> future "RTSP 3.0" (using SIP offer/answer), so that we could use more of 
> the existing ICE-for-SIP work.
> ???

Me and my co-authors have be looking a bit on making ICE work. However 
we have not yet updated it to reflect the latest changes in ICE. I hope, 
and I do say hope to be able to bring the draft up to date until the 
Prague meeting. But that will require my co-authors to do there share of 
work as I know I will not be able to do all the writing for that draft 
and get the base spec into shape.

Cheers

Magnus Westerlund