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

Joe Hildebrand JHildebrand at jabber.com
Tue Mar 16 23:38:24 UTC 2004

Thanks for the review.

Comments inline.

Joe Hildebrand

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

I'm fine with that.

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

Just so I understand, the two goals from this sentence are SIP and H.323?

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

Typo.  Will be fixed.

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

This will be a reference to the new stanza metadata JEP, if it passes
initial council review.  This is to encapsulate the need to send and receive
MIME headers through an XMPP/SIP gateway for maximum flexibility and

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

I agree, this is something we need to think about.  The first goal of this
iteration was to make it easy to write a gateway.  We may need to take
another pass through that makes it easier to write a client.... :)

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

Now it should probably go into the MIME header section.

> - 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 messages)?

There needs to be a note about this.  Perhaps this is the correct usage 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 SIP,

This part is totally up for discussion.  The original version used messages
to get around having to answer these questions... :)

> - there should be a re-invite example,
> - there should be an error case (busy or call refused).

Yes.  But we shouldn't reiterate the entire N pages of the SIP draft...

> 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

It may make sense for us to also be specifying what a gateway would do for
each step, since gateway interoperability is one of the key goals.

More information about the Standards mailing list