[Jingle] Call forking

[Olivier Crête]

On Mon, 2009-10-12 at 20:10 +0300, Diana Cionoiu wrote:
> Hello,
> 
> 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.

I agree

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

Shouldn't the device that has something important to say just answer the
call?.. Or maybe you want the user to be able to still answer from a
different device? I guess you still have the problem if you get
early-media ringing tone from more than one peer.

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

How do you suggest implementing it in the server? Should the server just
pick on device or should it notify both devices that there is a call?
How exactly? Etc.

> Regards,
> Diana
> 
> 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
> >
> >
> 
-- 
Olivier Crête
olivier.crete at collabora.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20091012/d54e5742/attachment.pgp>