Subject: RE: [MMUSIC] Notes from ICE call on 9/26

From: [email-masked]
Date: Thu, 28 Sep 2006 02:04:49 -0400 (EDT)

More detail the extra check on an unvalidated m/c-line proposal inline.

Jonathan Rosenberg <[email-masked]> said:

> ICE call
> September 26, 2006
> 
> Tim Moore
> Kevin Johns
> Philip Matthews
> Derek MacDonald
> Vicky Chan
> Rohan Mahy
> Jonathan Rosenberg
> 
> General agreement on symmetric RTP. Make a clear statement that
> symmetric behavior is what ICE produces. Question though: what is the
> problem with non-symmetric operation? Various network middlebox cases
> (not just SBCs), like qos-installers, monitors, diagnostic tools, were
> raised.
> 
> Need to clarify behavior of ICE for unidirectional media -
> sendonly/recvonly.
> 
> Agreement for the most part on the call that it is more desirable to
> have one side of the call pick a pair and communicate that to the far
> end rather than having each side independently pick its own
> candidate. This is choice 2a in my note on 9/26 entitled "ICE
> Finishing: Design choices". Jonathan still on the fence.
> 
> Long debate once again on the question of what to do when m/c-line
> doesn't match what is selected, and in particular the case where there
> is an SBC that has mucked with the m/c-line and left the candidate
> attributes in. ICE-10, per agreement at the last meeting, says to
> abort ICE. This is re-raised and folks want to allow ICE to
> proceed. Derek makes a proposal that if the m/c-line doesn't match, do
> a check on the m/c-line if you havent and if it works use it, else
> not. Some interest in this; questions on whether it would work with
> SBCs that pass RTP and not STUN.
I've thought this through a little more, here's how I see it fitting(and not) into ice-10.
The m/c-line would be added as a new candidate to the ice algorithm which has a special priority which is higher than the priority possible for any other candidate, in the waiting state.

The ice algorithm would proceed as normal if ice was not considered done, and this new candidate should be selected if it succeeds, if ice is allowed to proceed passt the first successful candidate for each component.  

If ice is considered done we open a can of worms.  If the answerer sees a mismatch in the updated offer( which indicates that ice is done), it could signal that ice needs to continue in the answer. The offerer is the controlling endpoint in ice-10, so if it sees a mismatch is could presumably extend ice discovering, although I don't think this behaviour has been described.  However, this would assume that both sides have the same timer values, or are expecting another o/a exchange.  It might be better to communicate this kind of ice-related information over an ice channel to avoid lots of SIP transactions, which are probably slower.

This seems to run into "when is ice done" issue, esp. which respect to how this is communicated to the other endpoint.  I'm not sure if its adding new complexity, or is exposing ice control issues we will want to resolve for other use cases.  Pesonally, I doubt this 'due diligence' check is likely to succeed except in ice-unaware networks.  If we add it, it should be optional and probably be enabled on a per-deployment basis.

-Derek

> No real conclusion. Jonathan strongly encourages folks to please post
> on the list during the week so we can have some forward progress prior
> to the next call.
> --
> 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
> 

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