[Standards-JIG] UPDATED: JEP-0111 (TINS)

CORVOYSIER David FTRD/DMI/REN david.corvoysier at francetelecom.com
Tue Mar 16 16:49:24 UTC 2004

I read the JEP carefully and I must say first that I think that
temporarily dropping SDPng in favor of SDP is the right way to go: SDPng
is by far not mature at this time (will it ever be mature is something I
can't tell but it hasn't received much support yet).

Now, I have a few comments:

3. Requirements

- It is clearly stated that the JEP aims at providing a way to establish
oob multimedia session not only between Jabber entities but also between
a Jabber entity and a foreign entity. Actually, I think it should be
more explicitly stated that only SIP users are targeted (I haven't seen
any reference to H323). 

- Having two separate goals may lead to a JEP that is too generic: you
will probably need a separate paragraph for each case, or two JEPs (see
other comments)

4. Protocol
- It is still specified that the INVITE may contain SDPng (replaced by

- the optional header or internet metadata is clearly a reference to
SIP. Since it should be part of a separate JEP, is it necessary to
specify it here ?  

6. Examples

- IMHO, Step 2 is only relevant when you use a gateway to the SIP world,

- If one of the goal of the JEP was not to maximize interoperability
with SIP, would the ringing event be handled that way ? I think a
jabber:x:event would be more appropriate,

- there is a <thread> in the iq on step 4 (It was previously meant to be
a call ID, but now ?).

- talking about call IDs, how do you maintain the transaction
consistency when embedding <tins> element in messages (with iqs you can
rely on the consistency of set/result, but no such mechanism exists for

- in step 4, the iq set / tins result combination is a bit odd to me.
The response is also weird: iq result /tins ack. I would rather have
imagined something like iq set /tins ok (yes, i know that in SIP ok =
result 200 ...), and only a result response as a reply. But again, I
understand it is done that way for the sake of the interoperability with

- there should be a re-invite example,

- there should be an error case (busy or call refused).

I summarized below my suggestion for a simplified negotiation:

A->B iq set/ tins invite with embedded SDP

B->A iq result

... Optional ringing event

B->A iq set/ tins ok with updated SDP

A->B iq result

... Call start

A->B iq set/ tins bye

B->A iq result

... Call end


More information about the Standards mailing list