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 [EMAIL PROTECTED] Collabora Ltd
signature.asc
Description: This is a digitally signed message part
