Subject: [MMUSIC] ICE call October 17, 1-2pm EST is ON

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 14:58:10 -0400

Agenda:

See separate mail with remaining open issues.

Join the Web Conference
1. Go to: http://meetingplace.cisco.com/join.asp?2203261

2. Fill in the My Name is field then click Attend Meeting

3. Accept any security warnings you receive and wait for the Meeting 
Room to initialize

Join the Voice Conference
1. From the Meeting Room, click on CONNECT (top left pane) and follow 
the instructions on how to have the system call you or simply follow the 
Voice only Conference instructions below

TO ATTEND A VOICE ONLY CONFERENCE
All Users
1. Dial into Cisco MeetingPlace (see Local & Global Access Numbers link 
above)
2. Press 1 to attend the meeting
3. Follow the prompts to enter the Meeting ID 2203261 and join the meeting

This works best from Internet Explorer.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Oct 2006 13:05:12 -0400

flow III, I don't have any issues with this.

Issue #10: ICE hammer. STUN checks themselves can cause lots of traffic
on the network, and can be used to launch an attack. What to do about
it?
Status: I posted some ideas on the list, no response.
<kcj> have to go find this posting. Must have missed it.

Issue #11: ICE pacing. Should we allow ICE checks to go faster if codecs
are at a faster rate?
Status: There was some discussion of this on the calls, no real
conclusion. We did agreed to make the Ta interval configurable and that
some research would ideally be needed to find a good value. But thats
about it.
<kcj> There might be some policy implications with the pacing. Case in
point is IMS and GPRS access networks. In this architecture from what I
can tell, there has to be a flow in place to even do connectivity
checks. It is unclear is a default flow can be used for such
capabilities. Further, they have expressed concern with ICE since the
STUN Relay accepts allocation requests on the same IP and port as the
actually media for relaying. This forces them to open a default rule to
allow for the allocation, but that then opens up to free media. One way
to address this is to install a default rule that has such policy
restrictions the media would not flow well. If we pace things to
quickly, then the rule may start to get in the way...

Issue #12: (never posted, in slides only). Question is whether to adjust
the retransmit interval for STUN when used with ICE. Argument is that
ICE transactions will often completely timeout
Status: My suggestion in the slides and in the related discussion on
behave was to leave it alone
<kcj> no opinion

Issue #15: Obfuscation of candidate lines to protect from generic ALG
Status: I propoed we not do this. There was agreement on the list from
Francois and Christer. But it has come up on the calls.
<kcj> I agree, we should not do this.

Holmberg-1: Christer proposed a way to return a STUN Server in a
REGISTER response. The idea is to find one in a local network.
Status: I proposed it be out of scope for ICE. Some back-and-forth with
Christer, not clear where we are. I still think its out of scope.
<kcj> I agree this is out of scope.

Holmberg-2: Christer raised an issue about handling of new media streams
in a re-offer. You basically need to start a fresh.
Status: I agree; with the ICE-states below, the idea is that there would
be a set of logic that applies in the 'running' state, anda  stream
enters the running state when its new. My plan is to make changes in
ice-12 to accomodate this. But would be good to make sure we're aligned
on the approach.
<kcj> Sounds reasonable.

Holmberg-3: ICE checks for inactive lines? b=3D0 lines?
Status: we agree ice checks are done if a line is a=3Dinactive. Christer
asks about b=3D0. Not clear.

Holmberg-6: Reliable provisionals
Status: Christer argues that the stuff in ICE about resending the 18x
until a stun request arrives is a hack, we should be requiring reliable
provisionals. No conclusion in discussions.
<kcj> I kind of agree with Christer especially since the first set of
STUN checks are going to fail given the race condition of setting up the
NAT bindings at the remote end. Seems you are guaranteed to always have
to re-send the 18x...

Closed
-------

Issue #1: Unified or separate checks across media streams
Conclusion: ICE-11 has separate checks, though still coupled via the
Frozen algorithm

Issue #2: 32 bit space limit for priorities
Conclusion: New formula in ICE-11 provides more than enough space

Issue #3: limits on number of media streams
Conclusion: Resolve in ICE-11 by having separate check lists for each
stream. Now there are no limits on the number of media streams

Issue #4: when is ICE done?
Conclusion: this is NOT in iCE-11 yet. We have agreed to signal
conclusion via the stun checks, and to have the stun checks indicate
which pairs are selected. ICE is done when the done flag has been set
for each component of each media stream by the controlling entity.

Issue #6: what to do if keepalives fail?
Conclusion: a few comments agreed wi:01C6F20E]
Cc: IETF MMUSIC WG <[email-masked]>

For folks who are having trouble getting the phone numbers from the 
website, here are the dialin numbers:

Frequently Dialed	
Phone Numbers:	US/Canada:         +1.866.432.9903
			Japan:                  +81.3.5763.9394
India: 		     +91.80.4103.3979
Australia: 	     +61.2.8446.5260
United Kingdom: +44.20.8824.0117

And the conference ID is 2203261.

-Jonathan R.

th my suggestion to do nothing, that
this was otuside the scope of ICE to solve

Issue #7: forking and receipt of media
Conclusion: ICE had this statement that you don't play media you receive
unless you had received a check. This completely fails with forking. So,
the functionality was removed from -11

Issue #13: when to send media?
Conclusion: We agreed (though this is not in ICE-11) that media could be
sent once done-ness is signaled via ICE, and could flow in both
directions. I will have that in ICE-12

Issue #14: ICE states? DO we need them?
Conclusion: Not in ICE-11, but we agreed I think that this made sense. I
was going to add the three states per media stream. The need for this
goes along with the resolution to #13.

Holmberg-4; Option tag?
Status: agreed to add an option tag. This will go into ice-12

Holmberg-5: port of zero? IP address of 0.0.0.0?
Status: we agreed that no checks are sent for port of zero. We agree
that checks are not sent for IP address of 0.0.0.0, and text needs to be
added to say that ICE endpoints cannot use that to implement call hold
when talking to another endpoint. That will go into ice-12

Matthews-1: spec mentions several times decisions made on whether you
are the offerer or answerer. What if an O/A is in progress while the
decision ahs to be made and this causes role reversal? Its a race
condition.
Status: agreed that, if needed, the role would be based on the initial
role of offerer vs. answerer

Thanks,
Jonathan R.

--=20

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Oct 2006 13:05:12 -0400

Frequently Dialed	

-Jonathan R.