[Jingle] Call forking

Diana Cionoiu diana-liste at null.ro
Mon Oct 12 12:10:56 CDT 2009


I do agree that forking is what user is expecting, but instead of doing 
something like SIP fork, we are using inteligent jabber servers.
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?
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.


P.S. -1 for forking in jingle.

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.
> 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 
> <mailto: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 <mailto:olivier.crete at collabora.co.uk>
>     Collabora Ltd

More information about the Jingle mailing list