[Standards-JIG] Jingle xeps

Joe Beda jbeda at google.com
Thu Oct 12 16:00:04 UTC 2006


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/c868e0e7/attachment.html>


More information about the Standards mailing list