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

Philipp Hancke <fippo@goodadvice.pages.de> Tue, 04 February 2014 20:56 UTC

Return-Path: <fippo@goodadvice.pages.de>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0181A011E for <stox@ietfa.amsl.com>; Tue, 4 Feb 2014 12:56:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmvEQaWD5pk2 for <stox@ietfa.amsl.com>; Tue, 4 Feb 2014 12:56:47 -0800 (PST)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF541A010F for <stox@ietf.org>; Tue, 4 Feb 2014 12:56:46 -0800 (PST)
Received: from [192.168.2.101] (p54973908.dip0.t-ipconnect.de [84.151.57.8]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s14Kuikm021128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <stox@ietf.org>; Tue, 4 Feb 2014 21:56:46 +0100
Message-ID: <52F15406.9090008@goodadvice.pages.de>
Date: Tue, 04 Feb 2014 21:56:38 +0100
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: stox@ietf.org
References: <20131212182625.7247.96401.idtracker@ietfa.amsl.com> <52B09E17.3030707@goodadvice.pages.de> <52EC22E4.5040700@stpeter.im>
In-Reply-To: <52EC22E4.5040700@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Stox] I-D Action: draft-ietf-stox-media-02.txt
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 20:56:50 -0000

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!