[Jingle] Call forking

Diana Cionoiu diana-liste at null.ro
Tue Oct 13 15:27:47 CDT 2009


On Tue, 13 Oct 2009, Sjoerd Simons wrote:

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

You seems to ignore the situation of the phone that has to handle a fork
from the other end.
What's happening when the person answers to one of the devices on the other
What's happening if i don't want to call all the devices or I have a device
that is not XMPP?

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

That's for each implementation to decide.

> > 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 :)

There is at least one, Yate which supports early media. Without early media
you can't make any PSTN phone calls, because you will not catch nice
messages like "the user is not in the covered area" or "the user is busy at
the moment".

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

Therefor the end user has to be able to make a decision for his devices, it
shouldn't be a default behavior.

> > 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 :)

Website was just an example on how we do it. I'm sure you can do it over
XMPP or using any other control form for algorithms and priorities.

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

The devil is in the details.

More information about the Jingle mailing list