[Jingle] Call forking

Justin Uberti juberti at google.com
Thu Oct 8 23:57:56 CDT 2009


My experience is that in practice, forking is the only comprehensive
solution. I was against forking for a long time but I really think it is
what the user expects to happen.
Our current approach at Google is to identify the most recently active
capable client and send the call there, but we sometimes we get it wrong,
perhaps because the user has just left their desk/switched browser tabs/etc.

Calling all endpoints and then sending a terminate message with a "cancel"
reason to the other endpoints seems like a reasonable approach. Doing ICE in
this situation may be very complicated though.

--justin

2009/10/8 Olivier Crête <olivier.crete at collabora.co.uk>

> On Thu, 2009-10-08 at 21:48 -0600, Peter Saint-Andre wrote:
> > On 10/8/09 3:38 PM, Olivier Crête wrote:
> > > Hi,
> > >
> > > If a contact I'm trying to call has multiple online resources. I want
> to
> > > call it, currently Gabble, our XMPP implementation, just picks one more
> > > or less randomly and tries to call it.
> >
> > Randomly? Without first determining which resources support Jingle?
>
> Well, randomly between all the resources that support jingle, but for
> the end user, it seems pretty random. If my mom has a N900 and any user
> friendly XMPP client (like Google Talk), she has no idea what these
> priority things are.
>
> > > I think the right approach is to
> > > do something like SIP forking, that is, try to call both and when one
> > > answers, cancel the other calls.
> >
> > And how well has forking worked out? Most SIP experts I've talked with
> > have said "avoid forking in Jingle if you possibly can".
>
> I'm not advocating doing forking, just calling all the possible
> resources. But yes, it is a bit like forking, without the madness (since
> the caller would  really be doing separate calls).
>
> > > The problem is that the non-answering
> > > resources will see it as a missed call. Maybe we should add a
> > > "answered-somewhere-else" reason for that case. Or is it what "cancel"
> > > or "success" are for ?
> >
> > That's one possibility. Another is XEP-0168, although people don't seem
> > to like that approach.
>
> Priority seems like a crap idea because it forces user configuration and
> doesn't solve the problem of having multiple hardware devices with the
> same account.
>
> --
> Olivier Crête
> olivier.crete at collabora.co.uk
> Collabora Ltd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20091008/063fd320/attachment.htm>


More information about the Jingle mailing list