[Jingle] Call forking
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
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
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 :)
The devil finds work for idle circuits to do.
More information about the Jingle