Re: [Stox] I-D Action: draft-ietf-stox-media-02.txt

[Philipp Hancke <[e-mail]>]

> Abstract:
>     This document defines a bi-directional protocol mapping for use by
>     gateways that enable the exchange of media signalling messages
>     between systems that implement the Jingle extensions to the
>     Extensible Messaging and Presence Protocol (XMPP) and those that
>     implement the Session Initiation Protocol (SIP).
>

A couple of comments, I just had some time (90 minutes :-)) to review this:

Section 5.1:
	the syntax and semantics of <description/> element are defined
	in [XEP-0167]

nit: 0167 defines the semantics of <description/> elements in the 
urn:xmpp:...:rtp:1 namespace. Giving 0167 again as an example for other 
description types in the next sentence is somewhat odd.

	<content/> 'name'
maps to a=mid: from RFC 5888 -- not sure if that is required for the 
basic usecase.
	<content/> 'profile'
0167 does (in it's current version) not have a profile. This was removed 
in Version 0.23 (2008-07-31).

	the 'action'  attribute [...] nine allowable values
No, it's 15. The missing ones are content-reject, description-info, 
security-info, transport-reject, transport-replace, transport-accept.

All the transport- are unused. description-info is for suggested 
application parameters (width, height), so we dont need it either. 
security-info is only used for xtls, so unused, too. I am not sure about 
content-reject.

Section 6:
senders can also have a value of "none" which maps to a=inactive. That 
is only in XEP-0166 and not in 0167.
Actually, Jingle has a cool message for hold which is content-modify 
(which only modifies senders). Why bother with two hold mechanisms when 
you can have three :-)

Section 9:
s/comas/commas/

XEP-0177 doesn't define <format/>. 0167 defines <parameter/> which is 
what you describe (and it does so in a wrong way, spec bug).

I think DTMF is the relevant example for bullet #3 (example from RFC 4733)
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Saul : I think I disagree with your comment about name being required by 
the xep's schema (which isn't normative anyway), both are required.
My take (after some discussions in jingle@) is that 'name' should be 
left empty and you should put the stuff to 'value'.


Section 10:
This section actually concerns me. Jingle is based on full jids 
typically. So in order to forward a call from a SIP entity to an xmpp 
entity, the gateway needs to determine which full jid to send to.
So it either has to have a presence subscription or can use presence 
decloaking (XEP-0276; deferred because of inactivity but works nicely).
If there are multiple possible resources, the gateway needs to decide, 
where to route the call.
As Emil mentioned, some people (i.e. me) are considering using 
<message/> for the session-initiate which would allow an xmppish way of 
forking (Jonathan: want to help out? :-)), but that is not ready yet.



Section 11.1:
the candidate in the example should probably have an id (at least where 
the 0177 schema is concerned which is not normative).
It might be worth noting (elsewhere?) that Jingle and SIP do ice 
restarts differently WRT to the generation parameter.

The last example contains a reasoncode='no-error'. I am not sure what 
old version of jingle this comes from, these days it's done with
<reason><success/></reason>


other issues:
routing of <iq/> (for the jingle->sip call-a-telephone-number usecase) 
that was raised at the end of the meeting:
this should go to the bare JID. Semantically, this means "don't route it 
to a client, server handles it". Here, the 'server' is handling it.


Peter: during the call I made a note "more disco#info examples", I think 
this was based on a comment by Markus about capability negotiation. I 
hope I remember the actual context when seeing the minutes.