Session Manager 6.3: Reduce Size of SIP INVITE Packet

[keschber]

We recently migrated to Session Manager 6.3 from an old version 5.2 SES. We have SIP endpoints that we need to establish calls to that are registered to SM. I believe I read somewhere that in SM 6.3 the SIP stack was increased to add some Avaya proprietary stuff, stuff we don't need in our environment. I see packets being fragmented coming out of the SM because the SIP INVITE is larger than the 1500 byte MTU of the Linux server.

I am looking for a way to strip out some of the unnecessary stuff in Session Manager to try to reduce the packet size.

Mostly we are able to connect anyway but we have a few sites that are connected via satellite. On these sites the INVITE never makes to the SIP endpoint. I have tried setting "Support Request History" to N on the SIP trunk in CM but that didn't seem to have any effect.

I don't think I can simply adjust the MTU in SM since in the newer versions we don't have root access. I'm not sure that would help anyway since the network will probably need to fragment the packet anyway farther down stream.

Any assistance is greatly appreciated.

 

[kyle555]

Either with an SBC, or ideally endpoints that support TCP

 

[keschber]

Thank you for your reply. I know I can do it through an SBC but am hoping I can find a different solution. The SBC adds complexity which, in my option is generally bad although sometimes necessary.

Our endpoints do support TCP but I believe they are all configured for UDP now. I'll check into that. Thanks!

 

[kyle555]

Yeah, I remember hearing about something in an SM adaptation that would strip out needless stuff, but I checked the admin guides for the latest releases and there's nothing there as far as stripping down the messages and leaving just the bare essentials.

hey, 4600 Avaya phones support SIP firmware but only UDP. If anyone can make them receive a call from CM/SM 6.3, I'd like to know!

 

[keschber]

I found this information. I assume this is what you are referring to regarding use of TCP?


Background: Avaya ASM 6.3.x introduces a new SIP stack, and as part of this additional features are included in the SIP messaging sequence known as headers. The addition of these SIP headers increases the overall size of a the SIP message.

Solution 2: Verizon SIP service provider is using UDP SIP which does not allow fragmentation of packets. If the service provider supports SIP TCP or SIP TLS both of these protocols support fragmentation of packets greater than 1500 bytes. Customer and SIP service provider could implement a TCP version of SIP.


In system Manager, under user management select the user and go down to CM Endpoint Profile and see what endpoint template is being used? Should be one for the 46xx phone.

 

[kyle555]

I don't know if that's going to help you.

- Adaptations are applied on SIP entities - to say, SIP trunks. Not to SIP stations

-Just because SMGR can manage a 4600 SIP station does not implicitly mean that that 4600 phone registers to Session Manager. In theory, you could manage a CM 5.2 with an SES on SMGR 6.3


Now, if you had SM1 for the UDP phones, and they registered directly to that SM without a CM or application sequence, and you had a trunk to SM2 that spoke to your CM and made SM1 have the Verizon adapter, maybe you could kludge/hack together something that made those phones happy. I'll presume you're not using 4600 phones and that the phones you're using are just SIP SIMPLE devices... but, how deep down the rabbit hole are you willing to go to avoid using TCP?

 

[montyzummer]

Try this is could be of assistance


To disable Do Not Fragment bit on Session Manager do the following:
Log into Session Manager.
Switch to the asset shell: asset-shell
Edit the following file: /proc/sys/net/ipv4/ip_no_pmtu_disc
Place "1" in the file: 1
Save file and exit.
Restart asset card: asset-sw restart




APSS (SME)
ACSS (SME)
ACIS (UC)

 

[keschber]

Thanks for the montyzumer. I'm not sure that will help though. The issue is not that SM fragments the packet, it's that the packet is over 1500 bytes. Even if I set the do not fragment bit in SM, another router down stream which also has a 1500 byte MTU will fragment it anyway. Our network is configured to forward fragmented packets but I believe it is once it hits the service provider network that the packet gets dropped.

 

[resetsys4]

I had recently where we upgraded the core to 6.3 and a remote g 700 to a g450 , the 450 just would not register , customer convinced that the G450 was faulty so I forced the s8300 server in the new g450 into lsp , with suspected faulty g450 , registered straight away , so then wiresharked it and the G450 was sending with payloads etc just over the 1500 mtu, the Cisco routers would handle ,
Anyway I think you are always going to have the problem unless you alter whatever edge device you have can be configured to accept larger mtu ( most can )

 

[kyle555]

I think its an inherent limit in UDP. If you can't fit the whole message in 1500 bytes, you get a 400 message to the effect of invalid message body

 

[resetsys4]

Of course if you truly dont need the CM features, turn of ims on the sig group (or create a new one ) then tinker to get the phones to do what you want routing wise.

 

[keschber]

Thank you all for the replies. I see the core of the issue being that Avaya added a bunch of Avaya proprietary junk (that we don't need) into the SIP header in SM 6.3 SIP stack and that made the INVITE packet over 1500 bytes. Avaya has come back and said there is not way to strip this stuff off in SM so they recommend running all of the SIP endpoints through an SBC. Of course there is added expense and complexity with this solution but the SBC will be able to strip the unnecessary stuff out and it will work. Clearly the application developers and product managers were so narrowly focused on the product that they failed to consider that it is part of a larger system that has to operate in the real world. Stepping off my soap box now. thanks again for all the suggestions and input. I'll be meeting with my extended team today to see what we can do to resolve it.

So far we have the options of switching to TCP, but there are concerns about latency, added overhead and things like that since this is going over a satellite link or putting an SBC between the SM and the SIP endpoint to strip out the unnecessary header information.