[Standards-JIG] Jingle xeps

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


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