[Standards] LAST CALL: XEP-0166 (Jingle)
lauri.kaila at gmail.com
Fri Nov 30 13:54:06 UTC 2007
2007/11/30, Peter Saint-Andre <stpeter at stpeter.im>:
> >> 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.
> So do you think we should keep the <busy/> informational message?
> Perhaps we need two kinds of busy, one is the error code and the other
> is the session-info message. But see below.
Do you mean error code and terminate?
> >> 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.
> Yes, that was the idea from your original message. So it seems that you
> suggest this:
> <iq from='juliet at capulet.lit/balcony'
> to='romeo at montague.lit/orchard'
> <jingle xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns'
> initiator='romeo at montague.lit/orchard'
> ==> reasoncode='busy'
Yes, it's very very close to what I had in mind. I thought about a
child element to <jingle> that could contain any content-specific
information. Not sure if that would add any value.
> Then the gateway needs to look for the reasoncode and map that to SIP
> If we add busy and unsupported-content then the reasoncodes would be as
> follows (not all these are related to session-terminate!):
> busy (maps to SIP 486)
> no-error (like SIP 183?)
> unsupported-content (maps to SIP 415)
> We might also want to add "timeout" (like SIP 408).
> What do you think?
Hmm. I don't understand no-error, but I guess those codes would be
usable. For other SIP error codes that don't have a meaning in pure
Jingle could map to general-error and use reasontext attribute.
reasontext='SIP 500 Internal server error'
More information about the Standards