[Standards-JIG] Jingle xeps

Matthew O'Gorman mogorman at astjab.org
Thu Oct 12 17:20:27 UTC 2006


even in a case like that (which i dont think will even scratch the
surface of how complicated things can get (i hate sip)) it should work
just fine if the client correctly simply responds as the server will
give alice/home the full from field. and if bob doesnt answer we
should do a redirect to voicemail/bob, as for bob/voicemail that would
still be an answer i would think just a delayed one.  Anyways I am
sorry if you think I am just trying to stir up trouble I just don't
get the point in another field.

Mog

On 10/12/06, Joe Beda <jbeda at google.com> wrote:
> 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
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>



More information about the Standards mailing list