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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Jun 2005 19:41:14 -0400

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 02 Jun 2005 15:41:28 +0200

Hi Jonathan,

A few comments in regards to RTSP. Although RTSP doesn't have re-invites 
it has re-setup that are used similar. Having said that however I am not 
greatly troubled if you change ICE to being offer/answer specific. 
Because I still think it is quite possible to do an not that difficult 
mapping of the different requests and information mapping.

See more below:

> as much from the ICE concepts as we can

Could be done, however I don't think we need to go that far. My 
preferred way would be to write the specification that  maps 
offer/answer ICE to RTSP.

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

Would be a major change to the protocol.

> ICE to facilitate nat traversal for streaming sessions.

Would be a new protocol, or at least RTSP version 2.0. I think MRCPv2 
has shown that this approach is possible. However as there specification 
shows this will still be quite a thick protocol specification.

> and I believe going (back) to an offer/answer approach is a good thing.

Being realistic, I think only alternative 1 could be possible today with 
the current interest in moving forward with RTSP.

Cheers

Magnus Westerlund

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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Jun 2005 01:01:32 -0400

> mapping of the different requests and information mapping.

OK, that is good.

> offer/answer ICE to RTSP.

That would be another option, yes.

> shows this will still be quite a thick protocol specification.

I'm not convinced you need to do much except for subset it, but I've not 
done a detailed analysis here.

> the current interest in moving forward with RTSP.

OK, in that case it would be ideal if someone from the RTSP community 
that wants to see ICE used with RTSP, could write a draft that maps o/a 
into RTSP. Probably that would be handy for a few things, not just ICE.

Thanks,
Jonathan R.