Lauri Kaila wrote: > 2007/11/30, Peter Saint-Andre <[EMAIL PROTECTED]>: >>>> 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='[EMAIL PROTECTED]/balcony' >> id='term1' >> to='[EMAIL PROTECTED]/orchard' >> type='set'> >> <jingle xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns' >> action='session-terminate' >> initiator='[EMAIL PROTECTED]/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='[EMAIL PROTECTED]/balcony'
id='term1'
to='[EMAIL PROTECTED]/orchard'
type='set'>
<jingle xmlns='urn:xmpp:jingle'
action='session-terminate'
initiator='[EMAIL PROTECTED]/orchard'
sid='a73sjjvkla37jfea'>
<busy xmlns='urn:xmpp:jingle:info'/>
</jingle>
</iq>
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
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
