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

[Philipp Hancke <[e-mail]>]

Am 31.01.2014 23:25, schrieb Peter Saint-Andre:
> 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. ;-)

heh :-)

[... snipping where +1]


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

Tricky... the xmppish way to do this would be to discover support via 
disco/caps.
[...]
>> 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.

Emil?

[...]
>> 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?

stox-media should use <parameter/>. We need to fix the spec bug in 0167 
at some point, but that's an XSF activity.

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

well, the general pattern is reused in some specs (0293 + 0294 IIRC), 
but those are RTP-related, so yeah.

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

uhm... no. This would be
<parameter name='' value='0-15,66,70'/>
Just show me your draft before submitting ;-)

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

Some things I discussed with Lance Stout at the recent XMPP summit about 
jingle+Forking+Push might be useful here. But those are probably too 
vague and untested yet, so we might need to invest some work into 
getting 0276 into a formally better state. It works quite well in 
practice, so...

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

good catch.

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

the discussion starts around 01:16, specifically Emil's comment at 
01:17:30 about sending from bare jids. IMO it's semantically ok to use 
bare jids on the XMPP side. But a hardcoded resource like "foo" doesn't 
hurt either and is likely to break less assumptions from client developers.

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

need to listen to the full recording again... more soon.

thanks peter!