Re: [dispatch] New I-D - SPIN - on voice/video interop between app providers

Jonathan Rosenberg <> Wed, 13 July 2022 02:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07C45C157B53 for <>; Tue, 12 Jul 2022 19:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.178
X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7IZc03j_pbLK for <>; Tue, 12 Jul 2022 19:50:11 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 7A6A0C157B57 for <>; Tue, 12 Jul 2022 19:50:11 -0700 (PDT)
Received: by with SMTP id 586e51a60fabf-10bf634bc50so12612020fac.3 for <>; Tue, 12 Jul 2022 19:50:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/Vn3CboHOrlcg6tp3jhHnuysftT8PhYc6BrgUvagOA8=; b=q0HJZdpYtrD/XBv/7/w+NDnPC4zzWb7W+ng6fBZAHTMqHKTI3y3A1hA8De8YIm9bod GIkVt8uiCpHdOLcWv2MP3BM60JBdIEhNsOS7KZoEVM1RZKXq/fQr4Y+pC90Yh/1XyRzL Ke+NQKZXtLKfCxAeSrZ6+2osXhPsMFgQo2jKIi+T8HDtweUhIziQNZ4pWlmPwPF3K0Ss W7t0j141tjl4tt2Ow8J1jB4ttdYnTFNekowofSrph6Qg1b+Xxu6tKKMZ8ZfGu2nSrQiP 7ZqFBPVNXaxNQyoHOhzJWUwA1aWF48pfJuY02VaiMo3XhuACM4aixO5tL/+b24K1OrA6 eQEA==
X-Gm-Message-State: AJIora+0Nk24KeAsj4Biyk/rzWUDPxLDsX7dOKCb9VEyPLbbtfpY3BBC 5ToqPplJpMoqlyB52Zk7xJvPSk08xeM=
X-Google-Smtp-Source: AGRyM1v/Em6psHo8/u7akSnEmxQi7s10OMyWzneIXt7GzY5QCma03vkbRFP6YPgzm4hD9P5J8oBZxw==
X-Received: by 2002:a05:6870:4720:b0:10c:5d1d:aecb with SMTP id b32-20020a056870472000b0010c5d1daecbmr3401450oaq.217.1657680610274; Tue, 12 Jul 2022 19:50:10 -0700 (PDT)
Received: from ( []) by with ESMTPSA id 188-20020aca05c5000000b00339c8aab320sm4897381oif.3.2022. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 19:50:10 -0700 (PDT)
Received: by with SMTP id t189so12879616oie.8 for <>; Tue, 12 Jul 2022 19:50:10 -0700 (PDT)
X-Received: by 2002:a05:6808:3082:b0:33a:4e2:3ae3 with SMTP id bl2-20020a056808308200b0033a04e23ae3mr674559oib.35.1657680609911; Tue, 12 Jul 2022 19:50:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Jonathan Rosenberg <>
Date: Tue, 12 Jul 2022 22:50:44 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Richard Barnes <>
Content-Type: multipart/alternative; boundary="000000000000e7a9d505e3a6d78d"
Archived-At: <>
Subject: Re: [dispatch] New I-D - SPIN - on voice/video interop between app providers
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jul 2022 02:50:15 -0000


On Tue, Jul 12, 2022 at 5:37 PM Richard Barnes <> wrote:

> Hi Jonathan,
> Thanks for putting this together.  Between this and the MIMI BoF proposal
> that Rohan submitted [1], there's clearly a lot of renewed interest in
> interop in these services, which I obviously support.  A couple of friendly
> amendments, in no particular order:
> Since we're so early in this effort, I would suggest that any work here
> *not* focus on the protocols themselves.  ("The SPIN Framework recommends
> specific protocols..." -- I mean that it should not recommend.)  Work on
> modern interoperable messaging is very early, and even in the voice/video
> space, while there's a lot of SIP, there's a lot of other things as well.
> Where this draft has a single URL, I would probably have multiple.

I'm with you on allowing multiples, but I do think there is value in having
a baseline recommendation, and picking something which is "least likely to
be much different than the lowest cost option that would be the minimum
effort required to comply with DMA". For voice and video, that is clearly
SIP. And for messaging, I suspect its a REST API. In other words, if the
major vendors had to implement an API and publish on their website, to be
compliant, for messaging this is almost certainly going to be some rest api
with verbs for sending and getting messages and so on. If they're going to
do that, may as well do it in a way that complies with a common spec. My
view is that, this whole effort fails if you dont optimize for solving the
adoption problem (and even then, it might fail).

> While connecting to phone numbers is indeed one of the major challenges
> for modern apps, it seems like the system you describe here is not
> inherently tied to them, especially since you're trusting STIR, not SMS for
> authentication.  The whole system would work if you have (a) a way to reach
> the terminating device, and (b) a way to authenticate the originating and
> terminating devices.  Opening up in this way could open the door to a more
> generic "how else is this person reachable" service.

Well, the trust chain requires a small number of trusted players - as you
yourself point out in your next comment -

> It seems like there are some practical issues with the proposal as
> stated.  For example, when is the user notified that someone is trying to
> contact them?  If it happens when the SPINvite shows up, then you'll have
> quite a long post-dial delay while the URL goes back and the application
> protocol sets up. If it happens when the INVITE shows up, then you've
> created an oracle for anyone to ask for someone's contacts, which seems
> bad.  Some prototyping here would be useful.

Ah great question. It happens when the INVITE shows up. And yes, that could
introduce this oracle problem. And that is why the draft suggests the usage
of a trusted intermediary - the mobile OS - to mitigate against this. The
SPINvitation is signed by the OS vendor and would be rejected if it doesnt
come from one of a handful that are trusted. Furthermore, the mobile OS
could employ any number of standard techniques for making sure the APIs to
request such signatures are not abused. Rate limits, app bans, etc.

> Overall, I agree this is an interesting area of work, especially if we
> focus on the discovery protocol.

Without a doubt the discovery protocol and voice/video chat protocols are
very separable in terms of specification development.

> --Richard
> [1]
> On Tue, Jul 12, 2022 at 10:13 AM Jonathan Rosenberg <>
> wrote:
>> Hi fellow dispatchers -
>> I wanted to call attention to the following draft submitted yesterday:
>> Abstract:
>> This document introduces a framework and a protocol for facilitating
>>    voice, video and messaging interoperability between application
>>    providers.  This work is motivated by the recent passage of
>>    regulation in the European Union - the Digital Markets Act (DMA) -
>>    which, amongst many other provisions, requires that vendors of
>>    applications with a large number of users enable interoperability
>>    with applications made by other vendors.  While such interoperability
>>    is broadly present within the public switched telephone network, it
>>    is not yet commonplace between over-the-top applications, such as
>>    Facetime, WhatsApp, and Facebook Messenger.  This document
>>    specifically defines the Simple Protocol for Inviting Numbers (SPIN)
>>    which is used to deliver invitations to mobile phone numbers that can
>>    bootstrap subsequent communications over the Internet.
>> Right now, we're looking to see if there is interest in working on this.
>> Comments welcome.
>> Thx,
>> Jonathan R.
>> --
>> Jonathan Rosenberg, Ph.D.
>> _______________________________________________
>> dispatch mailing list