Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice?

Peter Saint-Andre - &yet <peter@andyet.net> Mon, 09 March 2015 21:13 UTC

Return-Path: <peter@andyet.net>
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 05FB71A916B for <stox@ietfa.amsl.com>; Mon, 9 Mar 2015 14:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ghS3oFxjF675 for <stox@ietfa.amsl.com>; Mon, 9 Mar 2015 14:13:55 -0700 (PDT)
Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F861ACD75 for <stox@ietf.org>; Mon, 9 Mar 2015 14:13:27 -0700 (PDT)
Received: by iery20 with SMTP id y20so13939422ier.0 for <stox@ietf.org>; Mon, 09 Mar 2015 14:13:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1S83tNMq3v0ldtfk1avIl5fJxG2f/9qkBAQAd9NbIjk=; b=IUKctVHuKRo5dlHGG8c3yUouOc0D03WFMbbrevIW0LssISyOqBNpCQb5THutcGgLTg N5QxIr4aCHKjDe6eB7ZD//stYZpE3s4h0ix587D2Q/1uRaKY+Mi4svH+Nd+W/3YP+eG5 yuAb1y3dnegVmSzMnBaWLzBqbePIFpry63x9bKnqcZmDovmd2gRgBzAtMkat5NfHkoXD zdv/lZ67LmFv5Kbi65VEhivTtifIqcCo7RqXxCy/sAo8P0KYWb01cHknGUJIR1HT+0Ff IMJB1vfMR3z8dbf2SQckMe4wr/SMkBseSenk3yH+VVurTskE5k8Bo11rAj68mYlFimqk eXNw==
X-Gm-Message-State: ALoCoQlBYaVSahmNQpfRHXx2mZQNGDpRxGPlSms7Yg6hsIlFpXC7Bb+NtB9SkpEwt3LSQd96V1JC
X-Received: by 10.42.67.76 with SMTP id s12mr30635993ici.53.1425935607222; Mon, 09 Mar 2015 14:13:27 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 130sm12834937ioz.10.2015.03.09.14.13.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 14:13:26 -0700 (PDT)
Message-ID: <54FE0CF9.4090902@andyet.net>
Date: Mon, 09 Mar 2015 15:13:29 -0600
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Jonathan Lennox <jonathan@vidyo.com>
References: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> <532A645A.3080605@stpeter.im> <F3A5A36B-978D-4B50-8E24-A4D4AA77D370@ag-projects.com> <E95AAC63-26BF-48A9-A2D5-BEBB88B92567@vidyo.com> <5331BED1.3070202@jitsi.org> <CF55AE22-BC8C-41D2-ACDF-F36CB845A356@vidyo.com> <5331FF4D.8010900@stpeter.im> <E7E5D371-5B96-4D60-8C72-BF7DCA477465@vidyo.com> <54ED51AF.5040403@andyet.net>
In-Reply-To: <54ED51AF.5040403@andyet.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/-AHWJdM-t9T9-QPFHHeUJce_S44>
Cc: "stox@ietf.org" <stox@ietf.org>, Emil Ivov <emcho@jitsi.org>, Saúl Ibarra Corretgé <saul@ag-projects.com>
Subject: Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice?
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: Mon, 09 Mar 2015 21:13:59 -0000

On 2/24/15 9:38 PM, Peter Saint-Andre - &yet wrote:
> On 3/26/14 9:50 AM, Jonathan Lennox wrote:
>>
>> On Mar 25, 2014, at 6:12 PM, Peter Saint-Andre <stpeter@stpeter.im
>> <mailto:stpeter@stpeter.im>> wrote:
>>
>>> On 3/25/14, 12:03 PM, Jonathan Lennox wrote:
>>>>
>>>> On Mar 25, 2014, at 1:37 PM, Emil Ivov <emcho@jitsi.org
>>>> <mailto:emcho@jitsi.org>> wrote:
>>>>
>>>>> On 25.03.14, 15:15, Jonathan Lennox wrote:
>>>>>>
>>>>>> On Mar 25, 2014, at 4:55 AM, Saúl Ibarra Corretgé
>>>>>> <saul@ag-projects.com <mailto:saul@ag-projects.com>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> It occurred to me that SIP has a way of saying "do ICE, or
>>>>>>>>> fail the call": putting a "Require: ice" SIP option tag
>>>>>>>>> (from RFC 5768) in the SIP INVITE.
>>>>>>>>>
>>>>>>>>> Should we recommend this?  It clearly has the right
>>>>>>>>> semantics, and will prevent interop failure when a non-ICE
>>>>>>>>> SIP endpoint answers a XEP-176 Jingle call.
>>>>>>>>
>>>>>>>> Theoretically that makes sense.
>>>>>>>
>>>>>>> Agreed. Maybe a gateway could do ICE on behalf of the non-ICE
>>>>>>> capable endpoint, so can we say this is implementation specific
>>>>>>> and thus add a MAY to it?
>>>>>>
>>>>>> Right, of course.  I was talking about how you’d want to handle a
>>>>>> signaling-only gateway.
>>>>>
>>>>> There's also "XEP-0177: Jingle Raw UDP Transport Method" which is
>>>>> basically equivalent to ICE-less SIP.
>>>>>
>>>>> That said, I don't mind mandating ICE at all.
>>>>
>>>> Right, but there’s no way for a Jingle client to offer a choice
>>>> between XEP-176 and XEP-177, whereas RFC 5245 requires that both ICE
>>>> and fallback non-ICE be supported.
>>>
>>> Well, an XMPP initiator would not offer the ice-udp transport method
>>> if the responder didn't advertise support via XMPP service discovery
>>> (i.e., only advertised support for raw-udp). So, in general, fallback
>>> shouldn't really be necessary. However, we have defined a protocol
>>> flow for it just in case:
>>>
>>> http://xmpp.org/extensions/xep-0176.html#fallback
>>
>> The problem with that flow is the statement "Based on capabilities
>> information, the gateway knows that the SIP endpoint does not support
>> ICE”.  Unfortunately, SIP doesn’t really have any workable way of
>> providing capabilities information, which is why RFC 5245 (and so much
>> of the rest of SIP) is single-exchange fallback.

True.

>> An alternative flow is possible, where you only send the
>> transport-replace on the Jingle side if the SIP answer indicates no ICE
>> support, and then send a SIP re-INVITE with the addresses in the
>> transport-accept.  It’ll result a fairly substantial post-answer delay
>> before the media will get through, though.
>>
>> Here’s a sketch:
>>
>> Romeo                    Gateway                    Juliet
>>    |                         |                         |
>>    |   session-initiate      |                         |
>>    |   (audio definition)    |                         |
>>    |------------------------>|                         |
>>    |   ack                   |                         |
>>    |<------------------------|   SIP INVITE (ICE)      |
>>    |                         |------------------------>|
>>    |   transport-replace     |   200 OK (Raw UDP)      |
>>    |   (Raw UDP)             |<------------------------|
>>    |<------------------------|                         |
>>    |   ack                   |                         |
>>    |------------------------>|                         |
>>    |   transport-accept      |                         |
>>    |------------------------>|                         |
>>    |   ack                   |                         |
>>    |<------------------------|   SIP INVITE (Raw UDP)  |
>>    |                         |------------------------>|
>>    |                         |   200 OK (Raw UDP)      |
>>    |   session-accept        |<------------------------|
>>    |<------------------------|                         |
>>    |   ack                   |                         |
>>    |------------------------>|                         |
>>    |                    MEDIA SESSION                  |
>>    |<=================================================>|
>>    |                         |                         |
>>
>
> That seems reasonable but I'll give it more thought soon.
>
>> This flow also relies on the SIP side not changing its local IP address
>> and port in response to a re-INVITE with a changed address, or the XMPP
>> side not changing its in response to a transport-replace maintaining raw
>> UDP; otherwise, the gateway can get into an infinite
>> re-INVITE/transport-replace loop.
>
> Yes, we'll want to document those possibilities.

We didn't get to that yet because of the submission deadline, but the 
authors will discuss the remaining open issues soon (and I for one plan 
to do a complete review of the document and probably add a bunch of 
examples and call flows).

Peter

-- 
Peter Saint-Andre
https://andyet.com/