[Jingle] ICE-CONTROLLING / CONTROLLED

Justin Karneges justin at affinix.com
Tue Dec 1 11:33:58 CST 2009


On Tuesday 01 December 2009 05:28:47 Olivier Crête wrote:
> On Mon, 2009-11-30 at 11:12 -0800, Justin Karneges wrote:
> > On Monday 30 November 2009 03:15:22 Dave Cridland wrote:
> > > On Sun Nov 29 22:27:26 2009, Justin Karneges wrote:
> > > > According to the ICE draft, these attributes are used in
> > > > connectivity checks
> > > > to resolve role conflicts.  However, in XMPP there shouldn't ever
> > > > be a role
> > > > conflict, right?  It is clear who is the initiator and the
> > > > responder.
> > > >
> > > > XEP-0176 mandates the usage of these attributes.  Maybe this is
> > > > because the
> > > > ICE draft does also?  Section 7.1.1.2 says:  "The agent MUST
> > > > include the
> > > > ICE-CONTROLLED attribute in the request if it is in the controlled
> > > > role, and
> > > > MUST include the ICE-CONTROLLING attribute in the request if it is
> > > > in the
> > > > controlling role."
> > > >
> > > > Maybe we should drop this requirement from XEP-0176?  Or maybe we
> > > > could say
> > > > something like "the attributes MUST be included for consistency
> > > > with the ICE
> > > > draft but their values don't matter and are not ever used" ?
> > >
> > > I'm assuming that ICE libraries would typically mandate these
> > > attributes anyway. I don't see the utility in specifying that they
> > > "don't matter", aside from creating confusion.
> >
> > If XEP-0176 was literally ICE reframed in XML stanzas, then I might
> > agree. But the XEP is more of an ICE variant, and it has different rules.
> >  For example, the XEP specifies trickling candidates.  This means you
> > wouldn't (or wouldn't want to) pair a generic ICE library with Jingle. 
> > Instead, you'd use a XEP-0176-specific ICE library, or some multi-purpose
> > ICE library that supports the XEP-0176-isms.
> >
> > Because of this, I think it is entirely legit that someone (read: me)
> > would implement only the parts of ICE that matter for Jingle.  Two Jingle
> > clients will do nothing with the ICE-CONTROLLING/CONTROLLED attributes,
> > even though they are mandated by the spec, and that confused me as an
> > implementor.  Here I am setting the attributes but never reading them,
> > and it causes me to second guess my code and write to a mailing list.
>
> Really, I think you are being lazy. We should do our best to not
> differentiate from the ICE spec unless it really brings a lot of value.

The ICE draft says that conflict resolution is needed for third-party call 
control cases.  Whenever I see stuff like "third-party call control", my SIP 
alarms go off, and I don't think it's wrong to ask for clarification about 
it.

Appendix B.11 describes a case where a call controller sends out invites to 
two different clients and attempts to bridge them.  Both invited clients 
attempt to connect to each other simultaneously I guess, and both think they 
are in the controlling role.  Can this happen with Jingle?  Maybe it can, but 
it would be great if someone would say so.

-Justin


More information about the Jingle mailing list