[Standards-JIG] Jingle xeps

Matthew O'Gorman mogorman at astjab.org
Thu Oct 12 16:38:36 UTC 2006


however even in your said example you would have the from field
clearly specifying which end point answered.

mog

On 10/12/06, Joe Beda <jbeda at google.com> wrote:
> 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
> other directly.
> 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.
>
> Joe
>
>
> 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?
> > .
> > mog
> >
> > 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
> established
> > > (accepted) all further communication can go directly between the
> initiator
> > > and responder.  This lets a server or other entity broker a call but get
> out
> > > of the signalling once the call is established.  While it is possible
> for
> > > 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
> or
> > > other interesting call flows.
> > >
> > > As for ringing, busy and not in service -- these states don't apply to
> all
> > > sessions.  For instance, busy doesn't really apply to file sharing
> > > scenarios.
> > >
> > > Joe
> > >
> > >
> >
>
>



More information about the Standards mailing list