[MMUSIC] updated ICE spec submitted

[Jonathan Rosenberg <[e-mail]>]

I've just submitted an update to the ICE spec based on changes agreed to 
during the meeting, and based on several private comments and questions 
I've received since the last revision. Until the draft appears in the 
archives, you can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-08.txt

The changes are:

* specified that retransmit interval for provisional response when not
using PRACK is same as in rfc3262

* defined ice-pwd as either a session or media level attribute

* fixed text on jitter adaptation - talks about adapting buffers on
changes in source or destination address. Specfies that for audio
codecs which support marker bit for talkspurt indication, then set the
bit when a sender changes candidates for a media stream

* changed MAPPED-ADDRESS to XOR-MAPPED-ADDRESS everywhere, and
explicitly state that ICE implementations have to be compliant to
rfc3489bis, not just rfc3489, thus causing exclusive use of
XOR-MAPPED-ADDRESS.

* added section on Receiving media, and put some text in there on not
doing SSRC collision when there is a change in source IP address for
the same SSRC. Also added words in there about discarding media until
candidate pair enters Send-Valid.

* clarified that, if an ICE implementation communicates with one that
doesnt support ICE, its supposed to still use symmetric RTP and do RTP
keepalives of some sort (previous text said it had to follow the
guidelines in Section 7.13, which actually only apply to ICE
implmenetations)

* clarified that padding is not needed in base64 encoding, and why

* added picture explaining the use case for keeping a redundant
transport address from a different interface (same picture I presented 
during the wg meeting)

* for peer derived candidates, the IP address and port of the
connectivity check where compared against all existing candidates, and
if it wasnt a match, its considered a new candidate. What if its a
match to another candidate? This happens commonly, actually, when a
connectivity check is made between candidate pairs where one side is a
local transport address and that agent is behind an endpoint
independent binding NAT. Previously, the spec said nothing about this
case. Now, it says that this connectivity check serves to validate the
other candidate pair. This has the effect of speeding up convergence.

* updated IAB considerations section based on draft changes over last
few revisions


I believe this document is now ready for WGLC.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

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