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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 05 February 2014 02:42 UTC

Return-Path: <stpeter@stpeter.im>
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 349A31A01B7 for <stox@ietfa.amsl.com>; Tue, 4 Feb 2014 18:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level:
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 G1Yqi2hfJacH for <stox@ietfa.amsl.com>; Tue, 4 Feb 2014 18:42:53 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D51F01A01A6 for <stox@ietf.org>; Tue, 4 Feb 2014 18:42:52 -0800 (PST)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E431403AE; Tue, 4 Feb 2014 19:42:52 -0700 (MST)
Message-ID: <52F1A52A.1030603@stpeter.im>
Date: Tue, 04 Feb 2014 19:42:50 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Philipp Hancke <fippo@goodadvice.pages.de>, stox@ietf.org
References: <20131212182625.7247.96401.idtracker@ietfa.amsl.com> <52B09E17.3030707@goodadvice.pages.de> <52EC22E4.5040700@stpeter.im> <52F15406.9090008@goodadvice.pages.de>
In-Reply-To: <52F15406.9090008@goodadvice.pages.de>
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: Wed, 05 Feb 2014 02:42:56 -0000

On 2/4/14, 1:56 PM, Philipp Hancke wrote:
> Am 31.01.2014 23:25, schrieb Peter Saint-Andre:
>> On 12/17/13, 10:55 AM, Philipp Hancke wrote:

> [... snipping where +1]

Same.

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

Right. Given that we don't have such methods on the SIP side, I don't 
think we can make a strong recommendation here.

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

Hmm, XEP-0167 has lots of things like this:

<parameter name='foo' value='bar'/>

But if there's a spec bug in XEP-0167, let's discuss it on the 
jingle@xmpp.org list. :-)

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

Right, exactly. I was just being too terse in what I wrote.

> Just show me your draft before submitting ;-)

Keeping it updated in SVN for sure:

http://svn.tools.ietf.org/svn/wg/stox/

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

I've always liked that Presence Decloaking stuff in XEP-0276, but it's 
not implemented widely if at all, so I don't think it's correct for us 
to recommend it in draft-ietf-stox-media.

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

Ick, hardcoding. :(

But I'll listen to the recording soon and think about the issue more fully.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/