[Standards-JIG] Jingle xeps
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?
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
More information about the Standards