[Jingle] Call forking

Sjoerd Simons sjoerd.simons at collabora.co.uk
Tue Oct 13 12:06:07 CDT 2009


On Mon, Oct 12, 2009 at 08:10:56PM +0300, Diana Cionoiu wrote:
> Justin Uberti wrote:
> >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.

That's what Gabble does as well. Unfortunately when phones come into the mix
this falls apart. A phone is usually available all the time, but usually not
very active (or at least not the most active client).

At least for my personal use-case i don't think it's solvable without call
forking (or fork-like) behaviour. I tend to use my laptop in various places,
also i expect to basically always have my phone with me which is signed into
XMPP. Both of this seems reasonably and quite common. Now which device i want
to take phonecalls on depends mostly on whether i have a headset attached to my
laptop or not (if i have, then the laptop is preferred, otherwise the phone).
On the other hand some calls i might want to take on the phone so i can
easily walk away to a more private area then my desk in the office.

What this means is that you basically can't decide things beforehand, so
neither priorities nor resource application priority would work..

> >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.

You need to start setting up ICE sessions to all end-points, which isn't
necessarily complicated imho, just a lot of extra potentially non-necessary
work and packets flowing around :(

> I do agree that forking is what user is expecting, but instead of
> doing something like SIP fork, we are using inteligent jabber
> servers.

The xmpp server shouldn't plan any part in the setup of a jingle session.

> If i want to support fork, i will prefer to keep a list of user devices and
> call each one.  The real problem is not with the jabber server and the user,
> the real problem is with the other end.  Let's assume i call you Justin and
> you have 2 devices. One device is suppose to send me some early media telling
> me that you just went on a very long kayaking trip and the second one doesn't
> have early media and is sending ringing. Which one my client will play the
> important one or the ringing one?

That seems quite far-fetched. First of all, not all jingle clients support
early-media (i'm not sure any does atm), so having information in
your early media doesn't seem like a great idea. I would assume that if Justin
went on a long kayaking trip, he'd set his status to extended away with a
status message indicating this :)

In case you do call multiple clients in parallel, things will generally be
unsolvable when multiple ones send earlier-media, you'll just have to pick.

> Think about that when I'm calling you from a PSTN phone, where i
> don't get any other indication than ringing.
> 
> I do believe that forking it's a great idea, but implemented in the
> server where the user can have a smart web interface to make
> decisions, not a dumb fork in the protocol.

Things i really don't want to do while calling or being called includes going
to a website to decide on which device to use :)

  Sjoerd
-- 
The devil finds work for idle circuits to do.


More information about the Jingle mailing list