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

Richard Shockey <richard@shockey.us> Tue, 12 July 2022 22:25 UTC

Return-Path: <richard@shockey.us>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AB6C14F721 for <dispatch@ietfa.amsl.com>; Tue, 12 Jul 2022 15:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uU0mm5mq3xgR for <dispatch@ietfa.amsl.com>; Tue, 12 Jul 2022 15:25:18 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF835C14F6EB for <dispatch@ietf.org>; Tue, 12 Jul 2022 15:25:18 -0700 (PDT)
Received: from cmgw12.mail.unifiedlayer.com (unknown [10.0.90.127]) by progateway6.mail.pro1.eigbox.com (Postfix) with ESMTP id 5C8EA10041204 for <dispatch@ietf.org>; Tue, 12 Jul 2022 22:25:02 +0000 (UTC)
Received: from box5527.bluehost.com ([162.241.218.19]) by cmsmtp with ESMTP id BOJRoHyqCWg0EBOJRoJC7P; Tue, 12 Jul 2022 22:25:02 +0000
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.4 cv=Y4w9DjSN c=1 sm=1 tr=0 ts=62cdf4be a=KXpOjjFwo8kCkgxs2x2AJQ==:117 a=KXpOjjFwo8kCkgxs2x2AJQ==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=MKtGQD3n3ToA:10:nop_fastflux_from_domain_1 a=1oJP67jkp3AA:10:nop_fastflux_mid_domain_1 a=RgO8CyIxsXoA:10:nop_rcvd_month_year a=qMgonR0qfJAA:10:endurance_base64_authed_username_1 a=jqBRFv0mrdUA:10:from_fastflux_domain1 a=PeFO9FbFhS32YxYntvkA:9 a=doUQZJtgAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=YRLU8ZVIAAAA:8 a=48vgC7mUAAAA:8 a=1mHy1K9dAAAA:8 a=PiEfhnaacLXJmU5zcO0A:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=ivbTfD_dPm4A:10:phone_number_3 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=C21RrbpsFd_9L_SBXk0A:9 a=mvt1pUMheOqUIiSi:21 a=gKO2Hq4RSVkA:10:nop_mshtml a=UiCQ7L4-1S4A:10:nop_mshtml_css_classes a=hTZeC7Yk6K0A:10:nop_msword_html a=frz4AuCg-hUA:10:nop_css_in_html a=d0-0EwFVFT64L02gzcZV:22 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=G0fnPMQLLrhXuW0VSdpZ:22 a=w1C3t2QeGrPiZgrLijVG:22 a=YZZQrBN7PEZ4rQoNGmLO:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC: To:From:Subject:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YIlA7IDr7XDEhf9bMmEKb9caw9t4l3bBDsRjyPzmmM8=; b=h0ujF1ZVA6ZpIj46kE6T4XW/gt CUCbVgBeAMGVxYdSaZmFnRxVbmDfkCpGU2hE9W9Lbw4x1et43+xggWp7iifawvZz18SUf6ybohRj0 ttmSq0+n+dWO1/yGDNnigxI2u;
Received: from pool-100-36-48-45.washdc.fios.verizon.net ([100.36.48.45]:57956 helo=[192.168.1.214]) by box5527.bluehost.com with esmtpa (Exim 4.95) (envelope-from <richard@shockey.us>) id 1oBOJR-002LMR-6f; Tue, 12 Jul 2022 16:25:01 -0600
User-Agent: Microsoft-MacOutlook/16.63.22070801
Date: Tue, 12 Jul 2022 18:24:59 -0400
From: Richard Shockey <richard@shockey.us>
To: Richard Barnes <rlb@ipv.sx>, Jonathan Rosenberg <jdrosen@jdrosen.net>
CC: dispatch@ietf.org
Message-ID: <73C345C6-F9E6-484D-94D3-51FE6A0ACD23@shockey.us>
Thread-Topic: [dispatch] New I-D - SPIN - on voice/video interop between app providers
References: <CA+23+fFReP7fi2XmhGoxmeUph8F7HcABsFwriXPzBvuBPBXLMg@mail.gmail.com> <CAL02cgSYNUJ0juSU8Oyprz+zP_za32qOzf2id3iTfV+LC9hTAg@mail.gmail.com>
In-Reply-To: <CAL02cgSYNUJ0juSU8Oyprz+zP_za32qOzf2id3iTfV+LC9hTAg@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3740495101_1499469577"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box5527.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - shockey.us
X-BWhitelist: no
X-Source-IP: 100.36.48.45
X-Source-L: No
X-Exim-ID: 1oBOJR-002LMR-6f
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-36-48-45.washdc.fios.verizon.net ([192.168.1.214]) [100.36.48.45]:57956
X-Source-Auth: richard@shockey.us
X-Email-Count: 1
X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NTUyNy5ibHVlaG9zdC5jb20=
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/THYjOPNZ2jXQf7Y_RmWit6LRiAI>
Subject: Re: [dispatch] New I-D - SPIN - on voice/video interop between app providers
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2022 22:25:23 -0000

 

 

I’m sorry folks to pour cold water on any of this.

 

There is a very very long history of trying to get vendors to interoperate on advanced communications protocols. All of them have been a failure.

 

https://www.fcc.gov/america-online-time-warner-instant-messaging-interoperability

 

Discovery BTW is a long standing problem since yours truly chaired the IETF ENUM working group that ultimately produced RFC 6116.   

 

Yes ENUM is still alive and well and provides very valuable services to those with hearing impairments. The FCC 

 

https://docs.fcc.gov/public/attachments/FCC-14-5A1.pdf

 

 

https://www.fcc.gov/trs

 

 

If you even think of trying this with E.164 numbers RFC 6116  needs to be rewritten to deal with DoH.  Ask me how I know.

 

The FCC looked at interoperable video messaging to no avail. I know since I sit on the FCC NANC.

 

Its certainly worth looking at and Yes I’m coming to Phili. 

 

 

 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

www.sipnoc.org  (2022)

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

 

 

From: dispatch <dispatch-bounces@ietf.org> on behalf of Richard Barnes <rlb@ipv.sx>
Date: Tuesday, July 12, 2022 at 5:37 PM
To: Jonathan Rosenberg <jdrosen@jdrosen.net>
Cc: <dispatch@ietf.org>
Subject: Re: [dispatch] New I-D - SPIN - on voice/video interop between app providers

 

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.

 

--Richard

 

[1] https://datatracker.ietf.org/doc/bofreq-mahy-mimi-more-im-interop/

 

On Tue, Jul 12, 2022 at 10:13 AM Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:

Hi fellow dispatchers - 

 

I wanted to call attention to the following draft submitted yesterday:

https://www.ietf.org/archive/id/draft-rosenberg-dispatch-spin-00.txt

 

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.
jdrosen@jdrosen.net
http://www.jdrosen.net

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch