[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MMUSIC] updated ICE spec: summary of changes
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
jdrosen at cisco.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic