[Standards-JIG] UPDATED: JEP-0111 (TINS)
JHildebrand at jabber.com
Tue Mar 16 23:38:24 UTC 2004
Thanks for the review.
> 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