[Standards-JIG] Jingle xeps
jbeda at google.com
Thu Oct 12 16:29:39 UTC 2006
I'm not thinking of a simple redirect or gatewaying to legacy devices.
The scenario was this:
Alice wants to signal Bob. However, Bob is logged on with multiple
clients. Alice could use presence/rap to pick one and only one client to
call but that may not be the desired behavior. Instead, Alice wants all of
Bob's appropriate clients/resources/devices to ring. This is done with some
server side involvement:
1) Alice signals a call to Bob's bare JID.
2) Bobs server "forks" the call to each of Bob's resources.
3) All of the resources ring. Any messages relayed through the server from
individual resources have a "responder" attribute on them to mark where they
are coming from. (these include transport negotiation and "ringing"
notifications). However, the signalling still goes through the server.
4) At some point one of the resources accepts the call. The server can now
get out of the picture and drop its state as the clients can talk to each
5) If none of the resources accepts the call for XX seconds, the server
could then cancel all of those forks and start a new fork to a voicemail
system (or send back a redirect).
I think that it is obvious that we are going to want to handle call flow
scenarios like this at some point in the future. We can try to do this as a
new XEP or a new revision of 166 down the line if we can't work out all of
the details now.
On 10/12/06, Matthew O'Gorman <mogorman at astjab.org> wrote:
> Joe if you are doing a redirect shouldnt you just call the xep
> redirect? and if you are redirecting to a legacy device shouldnt the
> gateway keep track of said routing, as in the xep-100 gatewaying xep?
> On 10/12/06, Joe Beda <jbeda at google.com> wrote:
> > On 10/12/06, Matthew O'Gorman <mogorman at astjab.org> wrote:
> > > xep-166 (jingle)
> > > responder field, I noticed this was added on the final accept. I
> > > understand that initiator might be helpful in debugging who started
> > > the call and make logging easier, but responder? isn't that just
> > > added fluff that is not needed, i mean if we do a redirect it is a
> > > whole redirect when would you have a case where that information would
> > > be different?
> > > should the states of the call be in the signalling, ringing busy or
> > > not in service etc. Why are they shoved in xep-167?
> > I can speak to the responder attribute. The original thought behind
> this is
> > that it is similar to the CONTACT field in SIP. Once a call is
> > (accepted) all further communication can go directly between the
> > and responder. This lets a server or other entity broker a call but get
> > of the signalling once the call is established. While it is possible
> > the entity in the middle to stay in the signalling path this requires
> > storage for each session.
> > This middle entity could be used to implement things like call forking
> > other interesting call flows.
> > As for ringing, busy and not in service -- these states don't apply to
> > sessions. For instance, busy doesn't really apply to file sharing
> > scenarios.
> > Joe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards