[Standards-JIG] Jingle xeps

Joe Beda jbeda at google.com
Thu Oct 12 17:11:48 UTC 2006


Think of it this way -- the bare jid is acting as a proxy/traffic cop when
establishing the call.  In that case negotiation with multiple parites all
gets multiplexed through the same bare jid.

More detailed flow:

1) Alice/home sends initiate to Bob (bare)
2) Bob copies/proxies this and sends initiates to Bob/work and Bob/home.
3) Bob/work sends back a ringing response and starts negotiating the
transport.  This signalling is first sent to Bob (bare) and then forwarded
on to Alice/home.  It can't go directly to Alice/home as Bob wants to
monitor signalling for various purposes.
4) Bob/home similarly sends back provisional responses.
5) Alice/home starts establishing media connections with both Bob/home and
Bob/work.  Each of these is called a 'dialog'
6 option a) Bob/work picks up and sends an accept. This goes through Bob
(bare) and the Bob/home dialog is canceled.  All signalling can now go
directly between Alice/home and Bob/work
6 option b) Neither Bob/work or Bob/home picks up the call.  Bob (bare)
gives up and cancels both dialogs with and starts a new one to Bob/voicemail
(or perhaps voicemail/bob?).

For all of the steps where Bob (bare) is involved, IQs go between Alice/home
and Bob (bare) and between Bob (bare) and Bob/<resource>.  If Alice/home
wants to keep state for each dialog that dialog needs to be identified.  The
extra identification is the responder.

Again -- perhaps this is too complicated for now and is best left out.
However, I wanted to get the original reasons for the responder attribute
documented.

Joe

On 10/12/06, Matthew O'Gorman <mogorman at astjab.org> wrote:
>
> im sorry that this still isnt making since to me, if we cant rely on
> the from field given to us from the server as the correct responder to
> a call then shouldnt all messages contain initiator and responder
> field?  but that of course is ludicrous,  I don't think what you are
> trying to do is any less possible with out the responder field.   If
> you are redirecting to voicemail for example you should do a redirect.
> I really don't see why we need another field.
>
> mog
>
> On 10/12/06, Joe Beda <jbeda at google.com> wrote:
> > 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/6e55b9c9/attachment.html>


More information about the Standards mailing list