Re: [stir] [External] : Re: Making STIR SIP messages smaller

["DOLLY, MARTIN C" <[e-mail]>]

We have been bringing output from the IPNNI to 3GPP, though it always seems there are misalignments.

From: stir <[e-mail]> On Behalf Of Travis Russell
Sent: Wednesday, April 14, 2021 9:08 AM
To: Richard Shockey <[e-mail]>; Keith Drage <drageke=[e-mail]>; [e-mail]
Subject: Re: [stir] [External] : Re: Making STIR SIP messages smaller

Does anyone know of a source for STIR implementations globally? The links for the UK were very helpful by the way.


[[e-mail]]

Travis Russell | Cybersecurity Office |
Oracle Communications

+1919.205.6857 (o) | +1919.412.1167 (c)
https://www.linkedin.com/in/travisrussell1<https://urldefense.com/v3/__https:/www.linkedin.com/in/travisrussell1__;!!BhdT!xdo5B6CY4fU9-36bPMHQp1htr2VM2F39hKRu3btfjaW3jvAfOzdLRxYMBelW8g$>

5200 Paramount Pkwy
Morrisville, NC 27560
USA


[[e-mail]]

Oracle is committed to developing practices and products that help protect the environment


From: stir <[e-mail]<mailto:[e-mail]>> on behalf of Richard Shockey <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, April 13, 2021 at 11:19 PM
To: Keith Drage <drageke=[e-mail]<mailto:drageke=[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [External] : Re: [stir] Making STIR SIP messages smaller


+1 Keith.   I’ve heard of all the interop problems from the US and CA carriers. The UK is in process via NICC.

https://niccstandards.org.uk/wp-content/uploads/2019/03/ND1522V1.1.1.pdf<https://urldefense.com/v3/__https:/niccstandards.org.uk/wp-content/uploads/2019/03/ND1522V1.1.1.pdf__;!!GqivPVa7Brio!I-JOfYz61W4EpvFtPoAmv3H-2EiBlnoZsWkeWftKdA5XFKiX7LDq16mJvJPWuGP8SZg$>


and there are reports that the French are actively involved (I’ve heard from them) though their regulators want to use ETSI to run their SDO process.

https://www.etsi.org/<https://urldefense.com/v3/__https:/www.etsi.org/__;!!GqivPVa7Brio!I-JOfYz61W4EpvFtPoAmv3H-2EiBlnoZsWkeWftKdA5XFKiX7LDq16mJvJPW96kCSDs$>

South of France not totally surprising 3GPP still likes Croatia

Sophia Antipolis?


—
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us<https://urldefense.com/v3/__http:/www.shockey.us__;!!GqivPVa7Brio!I-JOfYz61W4EpvFtPoAmv3H-2EiBlnoZsWkeWftKdA5XFKiX7LDq16mJvJPWd5WThYE$>
www.sipforum.org<https://urldefense.com/v3/__http:/www.sipforum.org__;!!GqivPVa7Brio!I-JOfYz61W4EpvFtPoAmv3H-2EiBlnoZsWkeWftKdA5XFKiX7LDq16mJvJPWyH0utqY$>
richard<at>shockey.us
Skype-Linkedin-Facebook –Twitter  rshockey101
PSTN [phone]


From: stir <[e-mail]<mailto:[e-mail]>> on behalf of Keith Drage <drageke=[e-mail]<mailto:drageke=[e-mail]>>
Date: Tuesday, April 13, 2021 at 8:52 PM
To: <[e-mail]<mailto:[e-mail]>>
Subject: Re: [stir] Making STIR SIP messages smaller


I have memories of SIP message length being discussed way back in days of the SIP working group, i.e. pre SIPCORE, precisely in regard to the UDP versus TCP question. And all the issues relating to using TCP were raised at that time.

The answer at that time was essentially that when message lengths get long, TCP is the way to go, and that TCP is mandatory to implement in any case. No mileage was seen to be gained to making SIP more "UDP friendly".

Talking to some of my own implementors at the time, some of the problems identified with TCP were seen by them as just being poor software design, rather than inherent problems.

One point I would make is that if this is a problem, then STIR is the cause of the problem, rather than the body that needs to solve the problem. SIPCORE should be brought into the discussion.

Keith

Co-chair of the SIP WG at the time
   “For reliable transports, the response is normally sent on the
   connection on which the request was received.  Therefore, the client
   transport MUST be prepared to receive the response on the same
   connection used to send the request.”

I KNOW that there exist interoperability issues with TCP. But, if people implement TCP support wrong e.g., because they misunderstand the spec, shouldn’t we then instead clarify the spec?

Regards,

Christer




On Tue, Apr 13, 2021 at 4:14 PM Chris Wendt <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
[phone]
TransNexus

_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!GqivPVa7Brio!I-JOfYz61W4EpvFtPoAmv3H-2EiBlnoZsWkeWftKdA5XFKiX7LDq16mJvJPWdskxnLc$>




_______________________________________________

stir mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/stir<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!GqivPVa7Brio!I-JOfYz61W4EpvFtPoAmv3H-2EiBlnoZsWkeWftKdA5XFKiX7LDq16mJvJPWdskxnLc$>
_______________________________________________ stir mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/stir<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!GqivPVa7Brio!I-JOfYz61W4EpvFtPoAmv3H-2EiBlnoZsWkeWftKdA5XFKiX7LDq16mJvJPWdskxnLc$>