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. > 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. reasoncode='general-error' reasontext='SIP 500 Internal server error' -lauri
