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

Richard Barnes <> Tue, 12 July 2022 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F609C157B56 for <>; Tue, 12 Jul 2022 14:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1OqTIxpeyek6 for <>; Tue, 12 Jul 2022 14:37:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f34]) (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 02C67C157B5D for <>; Tue, 12 Jul 2022 14:37:12 -0700 (PDT)
Received: by with SMTP id d17so3535131qvs.0 for <>; Tue, 12 Jul 2022 14:37:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q9PmTdtIB3xtWNaxy9Jv+Azgl9AAeORLV00PLle2ZEM=; b=Ia2zd+bM/Xh32Q86wV9fVNO3jNvNavdmry9epZ82EmEyOkMSk4T2Xdb2Mubx+uQng2 2/auVdkwtDST/gNcNclvCd2pNWuEVvcHm1P0nebM6XlbEnbOLyDVhKc0QfNuiW+1yYQc TZh2iA3tT1UtQ0e8boV4mPZpfWLceVbZr39fuohYiL80BepOwf4JMqkw4z9VJjVuWt6V 7VYJfE3vgF4Q0fGGqm7EoOY6Zq2ryo1g0oYLary3bo8LpSnG26mg0vUIWhvfBKd5Jw6a n2SPlAjo5MMSLVYrfDY7a2bkXh1dFUIVCmHMm96mKrC8YoynCVTLjxSDDZ3RDTTpzj/+ HoHg==
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=q9PmTdtIB3xtWNaxy9Jv+Azgl9AAeORLV00PLle2ZEM=; b=WR4+f5biX9wAXGscfyak/+9Hmd30loJJdiKqZ+BboM763iYDQPLmpT+0zsLk1uNOOw Gk0ztHzngTpD6zZARNZEb66TMs1mpNOVTr5/l43LHYLYrqSBCi6F8vCP5NxkbbErVCcR 87Wxc5dXH1jm63Dfcv86F6TvbRaFES9tThwKd6CVxpfGCfYSKN8tURVVauV8t6d6bBln Rj0T9f9tb3f4Bh2lt05F/F5F1DnnSsqMpo3wfEFZe4g3o0j0g0/kgPnVySneV/1lNMVG 7T8yF6wObnXEvqgDj2P08P7MNB14UV7srwy68YAH2jFP+8e/s9n4nSNrHpqMU2kYzak/ pvpw==
X-Gm-Message-State: AJIora8euGa7lCvm98+4ArZB9P6XCieI8hwOcsdXjn7cFXW2Q0kk9MvT N/qEycNPEan6S542tlR/l7Wb7rCY2C91OsxVPpUcGw==
X-Google-Smtp-Source: AGRyM1uXedl2gKf9ttjNwDPXQ1VMUFd+IXcM8gOWflAVw87OXcNWNRl1D/x9wb4X5tYUUjUebSIV4QV+BvayTl30vcc=
X-Received: by 2002:a05:6214:5292:b0:473:6e86:74b0 with SMTP id kj18-20020a056214529200b004736e8674b0mr56046qvb.86.1657661831589; Tue, 12 Jul 2022 14:37:11 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Tue, 12 Jul 2022 17:37:00 -0400
Message-ID: <>
To: Jonathan Rosenberg <>
Content-Type: multipart/alternative; boundary="000000000000a1472905e3a278e0"
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: Tue, 12 Jul 2022 21:37:16 -0000

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.

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.

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.

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



On Tue, Jul 12, 2022 at 10:13 AM Jonathan Rosenberg <>

> 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