Re: [stir] Making STIR SIP messages smaller

[Roman Shpount <[e-mail]>]

Hi Chris,

There are different types of people who participate in the VoIP market.
There are large phone service providers who use equipment from large
vendors and generally standard compliant (however, this does not mean SIP
TCP works for them, but it works most of the time). You have other vendors,
which are small VoIP operators using either open source or equipment from
smaller companies. They do not participate in VoIP interops, do not follow
the standards, and generally rely on their vendors to provide working
equipment. These are the people who are affected. They also often
interconnect over the public internet, making the problem with fragmented
UDP worse for them.

I know that other headers make the SIP INVITE message larger, but for the
US PSTN call coming from a traditional SIP trunk, the INVITE size is still
around 1000 bytes. Adding Identity header makes it 1600 bytes. The smaller
customers are just now dealing with the interop when larger carriers switch
on the Identity, and things are starting to fail.

The fact that SIP over the reliable transports was badly designed in
RFC3261 makes the problem worse. For some reason, RFC3261 assumed that
sending INVITE over the reliable channel does not require retransmits and
that you can send responses to INVITE over the address in VIA. Both
assumptions are wrong and cause implementation issues. Essentially UDP was
tested more, so it is more stable. The way Identity is defined, it causes
transport to switch to TCP (or fragmented UDP), even though there is no
real reason for this to implement the desired functionality. All of this
results in my company spending time tracing call failures back to
origination.
_____________
Roman Shpount


On Tue, Apr 13, 2021 at 4:14 PM Chris Wendt <[e-mail]>
wrote:

> 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 <[e-mail]> 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 <[e-mail]>
> 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=
>> [e-mail]> 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 <
>>> [e-mail]> 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
>>>
>>> [e-mail]
>>>
>>> [phone]
>>>
>>> TransNexus
>>>
>>>
>>>
>>> _______________________________________________
>>> stir mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/stir
>>>
>>
>