[Standards] Jingle and call forking?

Olivier Crête olivier.crete at collabora.co.uk
Wed Apr 30 17:44:06 UTC 2008

On Tue, 2008-04-22 at 21:27 -0600, Peter Saint-Andre wrote:
> Paul Witty wrote:
> > Olivier Crête wrote:
> >> Hello,
> >>
> >> I was re-thinking about Jingle and I was wondering why one had to choose
> >> one resources and not be able to just send the invite to all of the
> >> responders resources and just accept the reply from the first one? That
> >> would be like the call forking of the SIP world.
> >>
> >>   
> > Any message not sent to a particular resource is handled by the server,
> > so in order to implement this the servers would have to be Jingle aware,
> > rather than just passing through messages to the clients.
> > 
> > On a client to client basis, you should have the presence information
> > from all the resources for a particular user, each with their specified
> > priority.  Service discovery on each resource can identify those with
> > Jingle support, and then session-initiate can be sent to the relevant
> > resource(s).  Choosing the highest priority available Jingle-supporting
> > resource seems like the most obvious choice, but I see no reason why
> > sessions can't be initiated to multiple resources.
> Right. The problem is if you don't have presence information because you
> want to start a voice or video chat with someone who is not in your
> roster. But then you can use stanza session negotiation to start the
> communication. Personally I don't get all worked up about this use case
> (presence is an add-on in the SIP world but core to XMPP), and we have a
> solution if you really need it.

This all makes sense (sorry for being a XMPP noob). I see only one piece
missing in the puzzle. I don't see a way to tell the other resources
that the call is cancelled because it was picked up somewhere else (so
that the UI does not show a missed call). Or am I missing something?

Olivier Crête
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080430/f58b38f9/attachment.sig>

More information about the Standards mailing list