Subject: [MMUSIC] Notes from side meeting on ICE, 2005-11-10 21.00-23.10

From: "Elwell, John" <[email-masked]>
Date: Mon, 14 Nov 2005 07:36:49 +0000

The purpose was to resolve an issue with ICE version 06 whereby it depended
on reliable provisional responses (PRACK), which is not widely implemented
at present.

Jonathan proposed a middle ground position. Subject to certain conditions,
as soon as a candidate has been validated successfully (both ways), you can
start sending media to that address, but must send an updated offer at some
stage. If PRACK is not available, you have to wait for 200.

Question over SRTP keying - uncertain whether any issues, e.g. to do with
windowing and different latencies on different candidates. May be solved by
different SSRCs with some implementations. This may occur even if we do
perform offer/answer exchange straight away. So there is a general issue
with SRTP, not introduced by ICE 06. Agreed to put SRTP aside until sorted
out RTP.

Issue that one side validates one path, but other side validates another
path due to packet loss.

Middlebox issue. Proposal from Cullen: if mc line works still go through
candidate list.

For STUN use over RTP, will frame STUN packet in similar manner to RTP.

Issues from slides: 

Issue 4: Fixed.

Issue 5 (pre-conditions): Fixed.

Issue 6: Addressed.

Issue 7. For jitter buffer change, need to set marker bit for audio (if
video lip synched, will take care of). Then look for marker bit change, port
change or SSRC change.

Issue 8. Implementations have to deal with it.

Retransmissions of unreliable 18xs - triggered by STUN request, not STUN
response (no max).

Remaining issue - if large number of candidates, could generate a very large
bandwidth of traffic with STUN retransmissions. Need to limit candidates
that are tried. Need to start thread on this topic.

Spec will require minimum of 32 bits of randomness at media level or at
session level.

RTCP optimisations, possible solution. For all candidates just check out
RTP. When find one that works, check out RTCP. May not be able to do this
optimisation if need RTCP quickly for synching video with audio. Concluded
it is a bad idea after all.

Participants happy with this approach. Jonathan to get out ICE 07 in next
few weeks.

Participants (apologies if I didn't read your handwriting correctly):
Rohan Mahy - [email-masked]
Jonathan Rosenberg - [email-masked]
Magnus Westerlund - [email-masked]
Cullen Jennings - [email-masked]
Eric Rescorla - ekr@????
Derek MacDonald - [email-masked]
Jason Fischl - [email-masked]
Tim Moore - [email-masked]
Alan Shen - [email-masked]
Tim Rang - [email-masked]
Steffen Fries - [email-masked]
Christian Schmidt - [email-masked]
Steve Casnen - [email-masked]
Colin Perkins - [email-masked]
Scott Lawrence - [email-masked]
Paul Kyzivat - [email-masked]
Robin Raymond - [email-masked]
John Elwell - [email-masked]

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