Subject: [MMUSIC] updated ICE spec: summary of changes

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Jul 2005 10:33:43 -0400

Folks,

As you may have seen, I posted an updated ICE spec:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-05.txt

this is a major revision, based on the conclusions of the previous IETF 
meeting. There are many changes, summarized below. The draft is not as 
polished as I would normally like, and terminology definitely needs work 
still, for example. However, I just ran out of time, and this ended up 
being a near total rewrite that consumed the entire weekend prior to the 
deadline.

There are also some open issues, which I will send some posts on separately.

Changes:

* basic mechanism now uses a re-invite to update the destination for 
media, thus separating the connectivity checks from the media handling. 
This is per discussion last meeting

* TCP-based candidates are now allowed. A lot of text was added to deal 
with this.

* STUN keepalives used for mid-session stuff, and rtp no-op for
communicating with non-ICE peers

* removed abstract protocol concept and associated terminology

* simplified section on address gathering, and added gathering of TCP
addresses. Added text that makes usage of TCP SHOULD strength, and
argues why its a good idea. If not used, it recommends to implement
and configure it off, as better than not at all.

* relaxed limitations on stun and turn derived addresses for endpoints
like pstn gateways. For them, ICE implementation is highly desirable;
it would allow its peers to connect even through symmetric nat without
a relay. However, since they always have a public IP, obtaining their
own derived transport addresses from stun and turn is not needed. I
wanted to lower the bar as low as possible for ICE implementation in
these endpoints.

* added allocation of TURN-derived TCP transport addresses to the
address gathering section

* removed text on conditions that other UNSAF protocols have to
satisfy in order to be used by ICE for address gathering. If someone
wants to use those with ICE they should write an I-D on it.

* specified more concretely how to use STUN and TURN for obtaining
derived transport addresses. The text there previously was vague and
not specific to TURN or STUN; it talked in terms of generic UNSAF
techniques.

* removed XML schema and the ICE mapping to XML

* relaxed constraint for each a=candidate attribute to have a unique
IP/port. Its not needed now, and I can think of reasons why someone
might want to do it...

* removed the user-frag and password attributes. Instead, the "id" is
used to construct the stun username and password. "id" needs to be
chosen with 128 bits of randomness. This simplified things by reducing
the number of identifiers and fields. The process for creating the id
was simplified.

* since there is a separate candidate for RTP and RTCP, there needs to
be a way to group them together, so it is known that both must
work. This is done by a candidate ID parameter.

* more clearly spelled out both offerror and answerer processing when
the peer is not ICE-enabled.

* added a section specifically about sending media, which mandates the
symmetric RTP property, even if the peer doesn't support ICE.

* removed much of the terminology, as things are simplified
now. However, needed to define a candidate separately from candidate
address - the latter being a sequence of the former. This was to
handle RTP/RTCP, where the candidate is really two addresses, both of
which need to be verified.

* allow hostnames in candidates, not just IP addresses

* If rtcp is not in used, the bandwidth modifiers have to be included

Thanks,
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: "Francois Audet" <[email-masked]>
Date: Mon, 25 Jul 2005 21:12:21 -0500

Hi Johathan,

Good job. This is indeed a major rewrite, but it does read much
better than before. I really like the overall simplification (including
removing the XML). It also addresses many of the points I had made before. 

Here is my initial set of comments:

- You changed the title to make the draft Offer/Answer specific. However
  the first 2 paragraph seems to still have the prior scope of "multimedia
  protocols" in general (talking about H.323, RTSP, etc.). I think it
  would be clearer if you removed that material since it now seems
  out-of-place with the new draft which is much more Offer/Answer 
  centric.

- In section 7.5.2, you should describe the granularity of the timers
  you are introducing. The way it is described right now, one may assume
  that it could be 1s. Having a implementation randomly chosing a value 
  of 0, 1 or 2 seconds (as opposed to say, between 0.00-2.00) is quite
  likely to result in the glare condition you are trying to avoid.

- Also in 7.5.2, you say "After the initial offer/answer... sets a timer
  Tu". I guess this means "right after sending the Answer in a SIP message"
  from the point of view of the answerer, and "right after receiving
  the answer in a SIP message" from the point of view of the Offerer. 
  (Maybe it is obvious...).

- Section 7.8 -> Change "travresal" to "traversal". I like the 
  idea of mandating symmetric RTP. I guess it should apply to both
  RTP and RTCP (and to UDP in general).

- Section 7.7: Is there any other reason than the "binding" keep-alive
  to continue to list the active transport addresses in the a=candidate
  lines? If the only reason is for keep-alives, I find it a little 
  heavy as a procedure compared to the no-opt (which should be supported 
  anyways for communication with non-ICE endpoints).

- The references to RFC 3489 should be to the 3489-bis instead.

- Your description below of "relaxed limitations on stun and turn 
  derived addresses for endpoints like pstn gateways" is much 
  clearer than what is in the actual document (I am assuming the
  second paragraph of page 12). The sentence "However, since they 
  always have a public IP, obtaining their own derived transport 
  addresses from stun and turn is not needed." is a useful
  sentence that is missing. The real point of course is that
  even if you know that an endpoint will never be behind a NAT/FW
  because it is always on the public network, it is still very
  useful to support ICE because of the reasons you mention. It is
  just that it will advertize a very small number of candidates 
  (perhaps just a public IP address and port). Somehow, this doesn't
  really stand out in the draft, unless you read your email 
  explaining the changes.

----
François AUDET, Nortel Networks
mailto:[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> Sent: Monday, July 25, 2005 07:34
> To: IETF MMUSIC WG
> Subject: [MMUSIC] updated ICE spec: summary of changes
> 
> 
> Folks,
> 
> * STUN keepalives used for mid-session stuff, and rtp no-op 
> for communicating with non-ICE peers
> 
> * simplified section on address gathering, and added 
> gathering of TCP addresses. Added text that makes usage of 
> TCP SHOULD strength, and argues why its a good idea. If not 
> used, it recommends to implement and configure it off, as 
> better than not at all.
> 
> * relaxed limitations on stun and turn derived addresses for 
> endpoints like pstn gateways. For them, ICE implementation is 
> highly desirable; it would allow its peers to connect even 
> through symmetric nat without a relay. However, since they 
> always have a public IP, obtaining their own derived 
> transport addresses from stun and turn is not needed. I 
> wanted to lower the bar as low as possible for ICE 
> implementation in these endpoints.
> 
> * added allocation of TURN-derived TCP transport addresses to 
> the address gathering section
> 
> * removed text on conditions that other UNSAF protocols have 
> to satisfy in order to be used by ICE for address gathering. 
> If someone wants to use those with ICE they should write an I-D on it.
> 
> * specified more concretely how to use STUN and TURN for 
> obtaining derived transport addresses. The text there 
> previously was vague and not specific to TURN or STUN; it 
> talked in terms of generic UNSAF techniques.
> 
> * relaxed constraint for each a=candidate attribute to have a 
> unique IP/port. Its not needed now, and I can think of 
> reasons why someone might want to do it...
> 
> * removed the user-frag and password attributes. Instead, the 
> "id" is used to construct the stun username and password. 
> "id" needs to be chosen with 128 bits of randomness. This 
> simplified things by reducing the number of identifiers and 
> fields. The process for creating the id was simplified.
> 
> * since there is a separate candidate for RTP and RTCP, there 
> needs to be a way to group them together, so it is known that 
> both must work. This is done by a candidate ID parameter.
> 
> * more clearly spelled out both offerror and answerer 
> processing when the peer is not ICE-enabled.
> 
> * added a section specifically about sending media, which 
> mandates the symmetric RTP property, even if the peer doesn't 
> support ICE.
> 
> now. However, needed to define a candidate separately from 
> candidate address - the latter being a sequence of the 
> former. This was to handle RTP/RTCP, where the candidate is 
> really two addresses, both of which need to be verified.
>