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

Peter Saint-Andre <> Wed, 05 February 2014 02:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 349A31A01B7 for <>; Tue, 4 Feb 2014 18:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.837
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G1Yqi2hfJacH for <>; Tue, 4 Feb 2014 18:42:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D51F01A01A6 for <>; Tue, 4 Feb 2014 18:42:52 -0800 (PST)
Received: from aither.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 2E431403AE; Tue, 4 Feb 2014 19:42:52 -0700 (MST)
Message-ID: <>
Date: Tue, 04 Feb 2014 19:42:50 -0700
From: Peter Saint-Andre <>
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 <>,
References: <> <> <> <>
In-Reply-To: <>
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-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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]


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

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