[Standards] LAST CALL: XEP-0166 (Jingle)
lauri.kaila at gmail.com
Thu Nov 29 22:54:00 UTC 2007
2007/11/29, Peter Saint-Andre <stpeter at stpeter.im>:
> However, we could retain the following flow but require the gateway to
> send 100 and 180, then send 486 when it receives the <busy/> error:
> session-initiate ->
> <- IQ-error <busy/>
> (That flow has a lot fewer stanzas!)
> I suppose the question is: what does busy really mean? Does the
> recipient's client know immediately that the user or device cannot
> accept the call? If so, the second flow is fine. If not, then we should
> retain the session-info <busy/> from the first flow.
I believe the busy code is used in both scenarios. But ringing doesn't
make sense if the user interaction isn't needed.
> Naturally a Jingle<->SIP gateway will need to worry about this kind of
> thing, but I don't know how much we should try to mimic the SIP flows in
> Jingle itself when used by native XMPP entities.
I wasn't worried about SIP interoperability in the first place... I
don't even like SIP. I just think it would be nice to have
<unsupported-content/> and <busy/> as a session-terminate reason
instead of iq error. IMHO it would make roles between 0166 and 0167
slightly more clear.
More information about the Standards