SIP call don't work in terminals avaya, but in x-lite yes. 1

[fabiopmoura]

Hello guys,

I'm having trouble performing sip calls on the customer, after much research I suspect it might be the settings "early offer". I installed x-lite on my computer and the connection is completed, but the terminals avaya the connection is not completed (one-X Communicator or 96xx hardphone). Can someone help me? How can I solve this problem?

The attached image are the invites, the above call is not completed and under yes.

I appreciate the help in advance

 

[kyle555]

Why are you using UDP? I'll bet SIP messages larger than MTU is the problem.

 

[fabiopmoura]

The SIP provider only supports UDP.

registered the same extension SIP in one-X and X-lite, because a complete and the another not?

if the problem is the same MTU, how can I solve it?

Look invite attachment.

 

[kyle555]

OK, so you're directly connected from SM to your provider. Xlite calls go out, but One-X Communicator calls don't...
What rejection do you get from the provider?
Can you write the capture from traceSM to a file with a pcap to see the size of the messages?
What if you turn off all the other codecs but G711 on One-X Comm to make the SDP smaller?

The SIP header removal feature in SM7 - and maybe your release might help to get the messages smaller. page 273:

https://downloads.avaya.com/css/P8/documents/101013827

 

[fabiopmoura]

I have a SBC after the SM, how can I do to lower the header it?

 

[kyle555]

If you have an SBC after the SM, then there's no reason you can't go TCP to the SBC and UDP from the SBC to the provider.

What kind of SBC do you have?

Either way, read up on the adaptations for header removal in SM7 - I believe it was included in the later releases of 6.3 as well, that might just be enough.

 

[fabiopmoura]

between the SM and the SBC the communication is via TCP, but between the SBC and the provider has to be UDP.

The versions are installed:
SM 6.3.17
ASBCE 6.3.6

I can not do step 6 in my version

5. In the Name field, type eRHdrs.
6. In the Value field, type “P-Charging-Vector, P-Location”
7. Click Commit.

 

[kyle555]

Why not upload a pcap from the SBC

 

[fabiopmoura]

see the attachment

 

[kyle555]

all I see are word docs and screen shots. Show me the packet capture from the SBC with the whole flow and the rejection message you're getting.

 

[fabiopmoura]

see the attachment

The first call was made by one-x and don't work, the second was taken by x-lite and work

 

[kyle555]

So, look at packets 1272 and 1271.

1271 says it's a UDP fragment of 1272, of 1516 bytes in length with 1272 being 341 bytes.

Now, look deeper in the packet to see the SDP and that the "content length" is 458 and it would appear obvious that all of that 458 bytes of content length cannot possibly exist inside an ethernet frame that's 341 bytes on the wire - that's your fragmented UDP packet.

Compare the same on 1786 and 1787 from your Xlite and you'll see that for whatever reason, it is being done in TCP.

Is it possible you have different server flows or endpoint flows or policy groups or other SBC configurations that cause one to go to your provider as UDP and the other as TCP?

Now, in packet 1791 - the invite I presume is from the SBC to the provider for your Xlite, you'll see everything first nicely in 1 UDP packet <1500 bytes.

You need to get your messaging down to under 1500 bytes to the provider.

If you can remove unrequired codecs like ISAC and G722/726 etc from your One-X Communicator, that would be a good start.

You might also be able to force that in the SBC by managing codec settings there to say "don't offer or accept anything not 711 or 729" for example.

The last appendix of these devconnect notes for some other provider show you how to do something like the header removal in SM from SBC scripts:

https://www.devconnectprogram.com/fileMedia/download/9c7275e7-e0d3-4b35-b882-e9e062903aec

 

[fabiopmoura]

Kyle555 once again thank you for the help you are providing me!

I do not have much practice in making adaptations in the SM and settings in the SBC, but I'm reading the manual you sent and trying to understand how I'll do it in practice.

no, the source and destination follow the same settings and flows for both softphones that are registered in the same notebook.

I'm testing with two softphones now, but I need the h323 stations registered in the CM also make the call through the trunk between the CM> SM> SBC

 

[kyle555]

No worries!

Just take a look in that doc for everything to do with Signaling Manipulation and there's instructions on how to create it and how to apply it to the outbound interface towards your provider.

Just removing user agent and plocation in your one-x example would remove 118 bytes+177 bytes respectively, so you'd get back a good chunk of data right there. If the SBC can also only offer 711/729 instead of everything your One-X is offering, you can trim that down from 458 bytes to something closer to the 273 bytes Xlite is offering.

Look the in SBC guide under Session Policies or Session Flows to see where you can lock down the codecs.

http://downloads.avaya.com/css/P8/documents/101001325