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/
- [Stox] Stox-media: Should XEP-176 translations ha… Jonathan Lennox
- Re: [Stox] Stox-media: Should XEP-176 translation… Peter Saint-Andre
- Re: [Stox] Stox-media: Should XEP-176 translation… Saúl Ibarra Corretgé
- Re: [Stox] Stox-media: Should XEP-176 translation… Jonathan Lennox
- Re: [Stox] Stox-media: Should XEP-176 translation… Emil Ivov
- Re: [Stox] Stox-media: Should XEP-176 translation… Jonathan Lennox
- Re: [Stox] Stox-media: Should XEP-176 translation… Emil Ivov
- Re: [Stox] Stox-media: Should XEP-176 translation… Peter Saint-Andre
- Re: [Stox] Stox-media: Should XEP-176 translation… Saúl Ibarra Corretgé
- Re: [Stox] Stox-media: Should XEP-176 translation… Jonathan Lennox
- Re: [Stox] Stox-media: Should XEP-176 translation… Peter Saint-Andre - &yet
- Re: [Stox] Stox-media: Should XEP-176 translation… Peter Saint-Andre - &yet