[Jingle] Call forking
Olivier Crête
olivier.crete at collabora.co.uk
Mon Oct 12 12:31:24 CDT 2009
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>
More information about the Jingle
mailing list