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

Brian Rosen <> Wed, 13 July 2022 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4EF9C188736 for <>; Wed, 13 Jul 2022 11:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=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 pnDYt1vqMOvu for <>; Wed, 13 Jul 2022 11:43:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::133]) (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 22DB8C188732 for <>; Wed, 13 Jul 2022 11:43:29 -0700 (PDT)
Received: by with SMTP id y12so992575ilq.10 for <>; Wed, 13 Jul 2022 11:43:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=A37CQEXi6OdalGxl8SSEi+Z4TQPW0VIYsQPXUIvkYvQ=; b=BAygxpBY6vRxqIDMMIApmIhFNoByg8OMhwNk7sidwZxa57p55bhmMKrZ608AUpyjxu sudniid4IhiUIp0mkccBAkMqLn/44Q85Zn/AV6hIq0wIc5FgkgPt0ipvUbO24As5qUpZ 4ZIs3ibNWoNRjOK1O7OkIID1oX+GxgLpGokmPxBBlLkUEgDOMKc97fTzwy/hoqj7soch +66yqFYmDa5t88kYrym34q8bOBSH7TnzvjX/v4jU8aoqUxEsyhef9F+zVpKO6AdcPj45 tun+doUebv+UWAJosaUSa2TfjfgTn+umAAIPNAKqzypG7My3qHFIVINAgN69MGdMLavi lxrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=A37CQEXi6OdalGxl8SSEi+Z4TQPW0VIYsQPXUIvkYvQ=; b=bSB8xAE5Vq16lkXfGFBsWI3guvmXWAC2q8hyR7Wdu/dpsqvyJQpEOOMOoboxfYRBSU 8761w8UsOPUgbLNno9za2y3UUwDpLoHJ1oPGl0Se9TsOutr/Vl/U/7jKg3Jy322hP6KK nAtOjYF18toIA+cdbXoRxdX426jxdmgCVcKNJYB13JYAo9LLeLM2F6OXFXprQd/KXvp/ kPiXu+Ip9r0Gb2lUbuj5ULjZ2w4i8Yp938UHjrJ1MQeDbySY5SHtSl96PHKH35cP5omn fe4S2TH9OVQh7MDWFZAQgf+bYh33k9NlO+Mgm0nipRgDw5WL9NOBJkLRDhGP3S9vfy7D Dejw==
X-Gm-Message-State: AJIora8kbHluQy8Aj6VRAJwZNstAS8kf+PUIJfDLCf5riz14+EcwUDcc axq+jXc9uyBlye8sG+R/iCyblQ==
X-Google-Smtp-Source: AGRyM1vw4FFVmr7b3S89NY/f2x3OGjx6zALcc9GNgjli9WlxZ2mtP4hCXrZ5LYHgQ9JPOAu6XYozrw==
X-Received: by 2002:a05:6e02:1809:b0:2dc:9d1d:98f with SMTP id a9-20020a056e02180900b002dc9d1d098fmr2627466ilv.36.1657737807918; Wed, 13 Jul 2022 11:43:27 -0700 (PDT)
Received: from ( []) by with ESMTPSA id p63-20020a022942000000b0033eb2f2ccfasm5545199jap.43.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2022 11:43:27 -0700 (PDT)
From: Brian Rosen <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A0F9309C-5C14-4B10-806A-A2C36B6517DB"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Date: Wed, 13 Jul 2022 14:43:24 -0400
In-Reply-To: <>
To: Jonathan Rosenberg <>
References: <> <> <>
X-Mailer: Apple Mail (2.3696.100.31)
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 18:43:32 -0000

Re MSRP, it’s easier to build a REST API to create a real time multimedia session, see WebRTC, but you proposed SIP.  That’s because everyone’s idea of the right REST API is different, but everyone can manage to make SIP work between those islands of REST APIs.  Ditto MSRP.

Re CloudSIP.  I don’t want to fight this one very hard, because I agree it makes things simpler, but lots and lots of folks have done it without CloudSIP.


> On Jul 12, 2022, at 10:56 PM, Jonathan Rosenberg <> wrote:
> inline:
> On Tue, Jul 12, 2022 at 10:34 AM Brian Rosen < <>> wrote:
> Definitely interesting.  Would be wiling to work on it.
> Is there a reason MSRP isn’t acceptable for the messaging default protocol?
> Well, its long in the tooth, and not really how most folks today are building messaging - which is by REST APIs. A big goal of the proposed approach (which is not clearly stated) is to try and minimize barriers to adoption by those who must adopt it. It's also way easier to build public cloud based messaging using REST APIs than MSRP. 
> Probably want to mention Real Time Text via RFC4103 (SIP signaled like voice and video).
> Are the cloud sip extensions actually necessary to get a minimum viable protocol for this purpose?
> Well, that's a fair criticism. THe rationale was what I was saying above - if you are building a pure software-based voip system on public cloud, its a mighty pain in the neck to do it without something like this. So the goal is to reduce barriers to entry.
> Might want to look at RFC9248 which is a SIP profile that uses the WebRTC media specs, DTLS-SRTP, and a bunch of other things to get a common client for audio, video and real time text.  Probably not entirely suitable for this purpose, but it’s a start of things that should be considered.
> I admit I had missed this one - will look, thx.
> Brian
>> On 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
>> <>
>> <>