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

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

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 
[e-mail] 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/