2007/11/29, Peter Saint-Andre <[EMAIL PROTECTED]>: > > 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. -lauri
