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

Peter Saint-Andre stpeter at stpeter.im
Fri Nov 30 18:17:28 UTC 2007

Lauri Kaila wrote:
> 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.

Well essentially at that point we'd have something like this (where we'd
allow you to include an info message in session-terminate)...

<iq from='juliet at capulet.lit/balcony'
    to='romeo at montague.lit/orchard'
  <jingle xmlns='urn:xmpp:jingle'
          initiator='romeo at montague.lit/orchard'
    <busy xmlns='urn:xmpp:jingle:info'/>

Not sure if it makes much of a difference, we just need to be consistent.

>> 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. 

Well no-error would be used for things like termination when there is no
problem (I'm just hanging up).

> For other SIP error codes that don't have a meaning in pure
> Jingle could map to general-error and use reasontext attribute.
> reasoncode='general-error'
> reasontext='SIP 500 Internal server error'

Yes we could do that.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20071130/4b66440d/attachment.bin>

More information about the Standards mailing list