Re: [stir] Making STIR SIP messages smaller

Richard Shockey <richard@shockey.us> Wed, 14 April 2021 01:34 UTC

Return-Path: <richard@shockey.us>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CA83A10B1 for <stir@ietfa.amsl.com>; Tue, 13 Apr 2021 18:34:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Level:
X-Spam-Status: No, score=-1.118 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, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us
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 dvpDAC-X9iyk for <stir@ietfa.amsl.com>; Tue, 13 Apr 2021 18:34:48 -0700 (PDT)
Received: from gateway23.websitewelcome.com (gateway23.websitewelcome.com [192.185.50.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55F53A10AC for <stir@ietf.org>; Tue, 13 Apr 2021 18:34:48 -0700 (PDT)
Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway23.websitewelcome.com (Postfix) with ESMTP id 114575DAB for <stir@ietf.org>; Tue, 13 Apr 2021 20:34:48 -0500 (CDT)
Received: from box5527.bluehost.com ([162.241.218.19]) by cmsmtp with SMTP id WUQZlFFvMb8LyWUQZlNzLV; Tue, 13 Apr 2021 20:34:48 -0500
X-Authority-Reason: nr=8
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=699ocUErz43Ml8hsdCl+2JsnTwNYrjSYPQ8KuLvFRjs=; b=hCEjx5GfQDrw4C/RcKyeqNNfg0 s97RI/bvli5THYvN72Rj/gu4z/DhonEQOpUqAxChxn8St6t7t+nEU/+Xo8Dfv1TRlegi6MHN09Ekm NhyXQsJe4Ph6A/ecL+2FEcSfa;
Received: from pool-100-36-18-145.washdc.fios.verizon.net ([100.36.18.145]:52303 helo=[192.168.1.156]) by box5527.bluehost.com with esmtpa (Exim 4.93) (envelope-from <richard@shockey.us>) id 1lWUQZ-001qas-Hw; Tue, 13 Apr 2021 19:34:47 -0600
User-Agent: Microsoft-MacOutlook/16.48.21041102
Date: Tue, 13 Apr 2021 21:34:46 -0400
From: Richard Shockey <richard@shockey.us>
To: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>, Chris Wendt <chris-ietf@chriswendt.net>, Roman Shpount <roman@telurix.com>
CC: Alec Fenichel <alec.fenichel@transnexus.com>, Marc Petit-Huguenin <marc@petit-huguenin.org>, Mary Barnes <mary.ietf.barnes@gmail.com>, "stir@ietf.org Mail List" <stir@ietf.org>
Message-ID: <81D5C626-7287-436C-A5AD-B2A299EEB053@shockey.us>
Thread-Topic: [stir] Making STIR SIP messages smaller
References: <adc8bd10-a04d-aff5-e03f-183f0d59c22c@petit-huguenin.org> <CAD5OKxvqYSRjaA_eR=nX4sNgTbAtQ3dSqqgAe0-y9EzbA-dRug@mail.gmail.com> <AM0PR07MB386063A2162B5C07319225D393739@AM0PR07MB3860.eurprd07.prod.outlook.com> <CAD5OKxuyT4bmNBYgSMN-9M-c1Tr=gO1rQAg1D7xGSYx=bP9K3A@mail.gmail.com> <5308A309-85DC-4440-ABE9-6C1EEB4E0FEE@chriswendt.net> <CAD5OKxsRh5pgYbc6ULL2c7nCUuAfQiM=r78vxkd0WWg0veDkjA@mail.gmail.com> <E0562367-B7E8-4935-A71A-60D2C105F850@chriswendt.net> <BN6PR11MB39211A0A9BB35EB34E1789C599709@BN6PR11MB3921.namprd11.prod.outlook.com> <19194256-B61E-47D6-B1F6-5317F2F7BE90@chriswendt.net> <BN6PR11MB3921F5DBEA3719F5DB0C31BC99709@BN6PR11MB3921.namprd11.prod.outlook.com> <CAD5OKxsswce0vHSZdc1UYS6ie2D7ut6ZDmc8MUX7Jnzyim9utQ@mail.gmail.com> <AM0PR07MB3860C3C820955494240B8FE0934F9@AM0PR07MB3860.eurprd07.prod.outlook.com> <CAHBDyN7SuuKb7kKGa1NN9rSpZ1s+wo4GVJq7DjRDt8UbaSHYrA@mail.gmail.com> <CAD5OKxugVqbw4s26Cixe30G3-5QaLLkyvn3L0j+QYfinVaf05g@mail.gmail.com> <27B6DE19-FD81-4204-8E8B-9E610A11884C@chriswendt.net> <AM0PR07MB3860A315725459B489F06FA1934F9@AM0PR07MB3860.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB3860A315725459B489F06FA1934F9@AM0PR07MB3860.eurprd07.prod.outlook.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3701194487_684679245"
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.18.145
X-Source-L: No
X-Exim-ID: 1lWUQZ-001qas-Hw
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-36-18-145.washdc.fios.verizon.net ([192.168.1.156]) [100.36.18.145]:52303
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/stir/9-Y7fWBFgp69r1uExTyitLEXNb8>
Subject: Re: [stir] Making STIR SIP messages smaller
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Apr 2021 01:34:54 -0000

 

<Sigh> This thread is SOOO boring.  We are all past the issue of TCP vs UDP and TCP keep alive at the edge.  Just get over it.  Resistance is futile.  Don’t be surprised if History Info is mandated over time to support Traceback. Then you will see a serious INVITE. 

 

The regulators are not being very forgiving these days. The FCC has issued some interesting orders re petitions for reconsideration and letters of excommunication to operators that won’t comply.

 

 

https://www.fcc.gov/document/fcc-issues-robocall-cease-and-desist-letters-six-voice-providers

 

https://www.fcc.gov/document/fcc-denies-stirshaken-caller-id-authentication-extension-petitions

 

 

https://www.youtube.com/watch?v=WnxJyEF4qLE

 

The CRTC has granted some extensions but the effect is very very clear.

 

https://crtc.gc.ca/eng/archive/2021/2021-123.htm

 

This is the #1 complaint I’ve seen in consulting with various operators for a project I’m undertaking for a well known regulator along with full Canonicalization of the E.164 number in the INVITE etc. AND AND the inability to negotiate a IP Voice interconnection agreement. 

 

Film at 11

 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

 

 

From: stir <stir-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>
Date: Tuesday, April 13, 2021 at 4:27 PM
To: Chris Wendt <chris-ietf@chriswendt.net>, Roman Shpount <roman@telurix.com>
Cc: Alec Fenichel <alec.fenichel@transnexus.com>, Marc Petit-Huguenin <marc@petit-huguenin.org>, Mary Barnes <mary.ietf.barnes@gmail.com>, "stir@ietf.org Mail List" <stir@ietf.org>
Subject: Re: [stir] Making STIR SIP messages smaller

 

Hi,

 

SIP implementations need to support TCP, and they need to support long messages. If we wanted to make SIP more compact, there are tons of things we could do.

 

And, if an implementations makes it or breaks it based on presence of the info parameter, that implementation is walking on very thin ice…

 

Regards,

 

Christer

 

From: Chris Wendt <chris-ietf@chriswendt.net> 
Sent: tiistai 13. huhtikuuta 2021 23.14
To: Roman Shpount <roman@telurix.com>
Cc: Mary Barnes <mary.ietf.barnes@gmail.com>; Christer Holmberg <christer.holmberg@ericsson.com>; Alec Fenichel <alec.fenichel@transnexus.com>; Marc Petit-Huguenin <marc@petit-huguenin.org>; stir@ietf.org Mail List <stir@ietf.org>
Subject: Re: [stir] Making STIR SIP messages smaller

 

Would be good to understand better why, i have not heard that feedback from the STIR/SHAKEN community lately or maybe folks have given up complaining :)  While there was much talk about it maybe 2-3 years ago, those conversations have been pretty quiet as of late. As far as i’m aware much of the equipment both commercial and open source and deployments have adapted and adjusted, but maybe there is parts of the eco-system that haven’t gotten there yet.

 

-Chris




On Apr 13, 2021, at 1:54 PM, Roman Shpount <roman@telurix.com> wrote:

 

Unfortunately, the message increase caused by the Identity header causes a call failure rate increase of at least a few percent. There is a substantial number of deployments affected by this and unlike things like History-Info, this feature is now required by law. 

_____________
Roman Shpount

 

 

On Tue, Apr 13, 2021 at 1:50 PM Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Yeah - like nearly 20 years ago when we added headers like History-Info.   And, really if you want to use a text based protocol, you surely can't have small message sizes as a design priority. 

 

On Tue, Apr 13, 2021 at 4:40 AM Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org> wrote:

 

>I agree that we need to figure out a way to make Identity headers smaller. As it stands right now, the Identity header with "shaken" PASSporT type adds around 600 bytes to an INVITE message.

>This makes typical SIP INVITE messages go from around 1K in size to 1.6K, which is bigger than the UDP MTU.

 

With or without Identity, didn’t that ship sail a long time ago? :)

 

Regards,

 

Christer

 

 

 

On Mon, Apr 12, 2021 at 5:39 PM Alec Fenichel <alec.fenichel@transnexus.com> wrote:

I guess what I am trying to say is that I think we should remove ppt from the examples because as you say, people tend to code to examples and smaller Identity headers would be ideal.

 

I don’t mean to hijack this thread, but I have been meaning to bring this up anyways and it is related. Is there a reason I’m just overlooking for requiring the “info” parameter when a full-form PASSporT is used? If not, can we make it optional? The reason I ask is that with OOB, the transit provider receives a PASSporT out-of-band and then needs to construct an Identity header. Because of the “info” parameter requirement, the transit provider must decode the PASSporT in order to determine the “info” parameter. This is the only reason that a transit provider needs to decode the PASSporT. This isn’t difficult so it doesn’t really matter, but I figured I’d ask about potentially making the “info” parameter optional. Also, it makes the Identity header smaller which is always a good thing.

 

Sincerely,

 

Alec Fenichel

Senior Software Architect

alec.fenichel@transnexus.com

+1 (407) 760-0036

TransNexus

 

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

 

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