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

[Peter Saint-Andre <[e-mail]>]

On 12/17/13, 10:55 AM, Philipp Hancke wrote:
>> 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:

Thanks, Philipp. Sorry about the delay in replying - as you might be 
aware I've had quite a bit happening since the interim meeting. ;-)

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

Agreed on all that. Let's use XEP-0234 (Jingle File Transfer) as the 
second example.

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

Right, those are for fallback scenarios and such.

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

At the core/general level, I agree.

> I am not sure about
> content-reject.

As you know, that's used by the recipient to decline the addition of a 
new content type to the session (e.g., the other party wants to add 
video to an audio-only session). Potentially we could map this to a SIP 
415 Unsupported Media Type response. However, this wouldn't round-trip 
very well because the stox-core document says to map SIP 415 to XMPP 
<not-acceptable/> whereas Jingle content-reject is not an stanza-level 
error but a Jingle-level response.

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

We'll add that to the first table in Section 5 (and number the tables 
while we're at it).

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

Sure, the more the merrier. :P

Is senders='none' implemented for hold functionality? We've been trying 
to define only what is in general use.

> Section 9:
> s/comas/commas/

That might have been a Freudian slip on the part of the authors. ;-)

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

Are you saying there is a spec bug in XEP-0167 or in the stox-media I-D?

(The Jingle specs need a general round of cleanup, so I would not be 
surprised about the former and you probably already mentioned this to me 
months ago.)

Naturally, this <parameter/> element works only for RTP communications, 
not other Jingle applications (say, file transfer). So we'll mention 
that in the text.

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

Yes, that seems better. Notice how RFC 4733 says the following things 
represent the same information:

(1)

       audio/telephone-event;events="0-15,66,70";rate="8000"

and

(2)

       m=audio 12346 RTP/AVP 100
       a=rtpmap:100 telephone-event/8000
       a=fmtp:100 0-15,66,70

Although (1) says events='', the events name doesn't appear in (2). So 
putting the stuff in the <parameter value=''/> (and empty name) seems 
reasonable.

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

The text here talks about the XMPP 'from' address that the gateway will 
place on provisional responses received from the SIP side. Since there 
might be multiple responses, we're saying to ignore the GRUU and make 
believe that the JID-equivalent of the SIP sender is a bare JID, not a 
full JID.

I'm not yet convinced that this is the best we can do in the SIP to XMPP 
direction, but it might be...

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

Yes, that might be helpful.

> 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 needs to have a 'component' attribute too, per XEP-0177.

> It might be worth noting (elsewhere?) that Jingle and SIP do ice
> restarts differently WRT to the generation parameter.

Agreed, we have an open issue to add some text to Section 5.4.

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

Noted, will fix.

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

I'll need to listen to the audio recording in order to know the context 
here.

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

As in all of these mapping specs, we try not to reply too much on 
discovering the capabilities of other entities, since SIP doesn't have 
any reliable facilities for that. But if you remember the context, let 
us know. :-)

Thanks again,

Peter