[Standards] LAST CALL: XEP-0166 (Jingle)

Lauri Kaila 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'
>     id='term1'
>     to='romeo at montague.lit/orchard'
>     type='set'>
>   <jingle xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns'
>           action='session-terminate'
>           initiator='romeo at montague.lit/orchard'
> ==>       reasoncode='busy'
>           sid='a73sjjvkla37jfea'/>
> </iq>

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
> syntax.
> 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)
> connectivity-error
> general-error
> media-error
> 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 mailing list