Reducing length INVITE

Hello all,

I have a weird question: my trunk provider is using SIP ALG in their network. How bad that may be (especially for a VoIP provider), the real problem is that their SIP ALG is blocking my INVITES because the packets are too long.

I therefore would like to strip out any unneeded headers in my INVITE. Below this message you can find an example INVITE to my trunk provider.
I found someone else who seems to have the same issues: http://inside-out.xyz/technology/sip-signaling-issues-with-long-udp-packets.html


22:26:55.288146 IP (tos 0x0, ttl 64, id 55684, offset 0, flags [none], proto UDP (17), length 1389)
2.2.2.2.onscreen > 1.1.1.1.sip: SIP, length: 1361
INVITE sip:00318000403@1.1.1.1 SIP/2.0
Via: SIP/2.0/UDP 2.2.2.2:5080;rport;branch=z9hG4bKZS2XD7m3BH1cp
Max-Forwards: 69
From: "xyz" <sip:00314012345@2.2.2.2>;tag=F9F5gp2jtmrKF
To: <sip:00318000403@1.1.1.1>
Call-ID: 2fe4773a-320a-1236-b4ad-00163c0a70e8
CSeq: 114015944 INVITE
Contact: <sip:gw+75ec8c72-548e-4938-85e9-8dd669290504@2.2.2.2:5080;transport=udp;gw=75ec8c72-548e-4938-85e9-8dd669290504>
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Proxy-Authorization: Digest username="userN4me", realm="fakeRealm", nonce="XXXXXXXXXXXXX", algorithm=MD5, uri="sip:00318000403@1.1.1.1", response="18476278258947245023"
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 268
P-Access-Network-Info: IEEE-EUI-48;eui-48-addr=BC-05-43-C5-36-F0
P-Emergency-Info: IEEE-EUI-48;eui-48-addr=00-0B-82-73-CE-8D
X-FS-Support: update_display,send_info

v=0
o=FreeSWITCH 1508684879 1508684880 IN IP4 2.2.2.2
s=FreeSWITCH
c=IN IP4 2.2.2.2
t=0 0
m=audio 19136 RTP/AVP 8 0 101 13
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20

Actually i just got confirmation from my SIP provider that they are blocking my UDP packets actively because when authentication is involved the packet is larger than their firewall allows. So i tried UNsetting some headers in the outbound routes, but that did not have any effect.
How can i control the headers FreeSwitch is sending to my VoIP providers?

Thank you DigitalDaz, but my trunk provider is not accepting TCP packets, so i am bound to UDP. I have UNset a few headers in the outbound route and now things seem to go well.. I fully agree this is a non-ideal situation this trunk provider has created, but i will have to live with this.

Hi DigitalDaz,

I agree they are doing something extremely...uncompliant. But i have evaluated virtually ALL carriers here in NL and this is a rather minor issue believe me. In one case the carrier stopped routing emergency calls without notifying me... I found out when someone had a hart attack. So the problem here in North-West Europe is finding a good carrier where i can get access without routing millions of minutes to per month.
Is the article in the RFC btw 18? I would like to confront them with that...

Hi DigitalDaz,

Thank you. That was indeed the exact section i was looking at. They are using FreeSwitch btw. So i am rather surprised that their system is so incompatible with FS and works flawlessly with Asterisk. I can only guess this is because they see FS as a SBC and not as a UAC.. As i said before: i do not agree with them and i think not following the RFC's creates a sort of "intranet" that makes interoperability very very difficult. I will ask them about the section 18. Thanks again!