[Standards-JIG] Jingle xeps

Joe Beda jbeda at google.com
Thu Oct 12 16:48:29 UTC 2006


No -- without another header it isn't possible to multiplex multiple
"dialogs" in a session through the server.

The requirements during an early session (i.e. before accepted) are this:
1) All signalling goes through the server so the server can modify the call
flow (this includes redirecting to voicemail)
2) Negotiation between the initiator client and the final endpoint
(responder) need to be identified.  None of the IQ fields can be used as
those are (from the point of view of the initiator) just the initiator and
the server.

This requires another header to key the dialog.  A session is identified by
the (initiator,sessionID) combo but the dialog is identified by the
(initiator, sessionID, responder) combo.  In this sketch of a proposal,
there are multiple dialogs per session until one of the dialogs is
confirmed/accepted.  At that point there is only one dialog and the server
can bow out of the picture.

(I hate to introduce the idea of dialog here -- perhaps we can try to find a
way to put this in another XEP or the next version of the spec as we get
more experience building this stuff out.  The idea of a dialog should only
come in as you start doing these more complicated call flows)

Joe

On 10/12/06, Matthew O'Gorman <mogorman at astjab.org> wrote:
>
> 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
> > > >
> > > >
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061012/ad2e5a6f/attachment.html>


More information about the Standards mailing list