Subject: RE: [MMUSIC] ICE: move away from generic framework to offer/answer

From: "MARJOU Xavier RD-MAPS-LAN" <[email-masked]>
Date: Wed, 15 Jun 2005 10:31:39 +0200

Hi,

Personnally, I have a dream ; that SIP and RTSP evolve to merge into a
single protocol (eg: modifications within SIP to integrate the delta
needed for RTSP features). For some works like NAT, work would need to
be done only once.

Xavier 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jonathan Rosenberg
Sent: jeudi 2 juin 2005 01:41
To: IETF MMUSIC WG
Subject: [MMUSIC] ICE: move away from generic framework to offer/answer

One of the complaints I have gotten about the ICE draft from many
different sources is that it is too complicated. People I know who I
consider very smart have told me that reading it "made their head hurt".

This is a recipe for interoperability problems, and so one of my goals
in this revision, beyond moving to the imroved re-invite based approach
we discussed last IETF, is to simplify the document.

One of the sources of complexity is the fact that the spec is written as
a meta-protocol. Its defined in terms of exchanges between abstract
entities (intiator and responder) with abstract protocol messages
defined in XML. The document then maps the XML into real protocol
messages (specifically, SDP).

The reason we did that was to allow ICE to be used by RTSP for NAT
traversal, since RTSP is not offer/answer based. However, the new
mechanism discussed in Minneapolis relies on a re-invite to promote a
candidate to actual usage in the m/c line. RTSP has no support for
re-invites, and thus it won't be able to use ICE with this new
mechanism, at least not directly (more on that below). As such, in the
interests of simplifying the document for its primary customer - SIP -
I'd like to convert this to be offer/answer based.

So what about RTSP? I think there are several paths:

1. define a separate specification that is specific to RTSP, borrowing
as much from the ICE concepts as we can

2. define an extension to RTSP so that it uses offer/answer

3. if ICE is needed with RTSP, then use SIP and offer/answer to set up
the session, focusing RTSP on control. That allows for direct usage of
ICE to facilitate nat traversal for streaming sessions.

I personally like (3) a lot, but it can be discussed downstream. I'd
like to focus on getting the main ICE draft done and working for SIP,
and I believe going (back) to an offer/answer approach is a good thing.

Comments?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Jun 2005 05:17:58 -0400

> needed for RTSP features). For some works like NAT, work would need to

This comes up periodically. Unfortunately, this faces a number of 
practical hurdles:

- RTSP and SIP are widely deployed, in literally millions of pieces of 
software. Merging them would cause interoperability issues, with no 
major advantage in functionality.

- RTSP has a much more limited scope, which makes it relatively easy for 
implementors to grasp. SIP has dozens of extensions, leaving alone 
abominations like SIP-* (where * is just about any letter of the 
alphabet). SIP needs those, since it has much broader scope.

- RTSP and SIP URLs are fundamentally different, and justifiably so 
(file vs. person).

- Any merging activity would take a decade, given the current speed, or 
lack thereof, in the IETF. By that time, industry confusion will be such 
that only proprietary protocols will remain. It's taking several years 
just to rev the RTSP spec, with modest modifications.

With hindsight, it would have been nice to have a common framework for 
both protocols, so that infrastructure such as ICE works across both. 
Unfortunately, hindsight is good for bar discussions, but not IETF and 
protocol realities.

Henning