Avaya CM 5.2.1 co-resident SES 5.2.1 SIP Trunk not working

[edcelf]

Hi everyone,

I really need your expertise with this!

I am implementing a SIP Trunk from Avaya CM to a third-party SIP Provider through a co-resident SES, but it seems that it is not working. I have already referred to different Application Notes but it is still not working. I have also configured SES according to what the Application Notes stated. Licenses for SES are still working, certificates are far from expiry, conflict trunks we're removed.

I always get a Network Failure for my outbound call and incoming call are not passing through (with no trace capture on ASA), SES Trace logger has no trace capture of my test calls.
I configured my SIP Domain to be the same as the address of the procr.

Do we really need to configure a DNS for the Avaya CM? or is it okay if it is left blank?

Also, can we implement direct SIP Trunking from CM to SIP Provider without the co-resident SES?

These are some of the application notes I have referred to:

https://www.devconnectprogram.com/fi...6-fe7b6188230c

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

Really hope someone can help me with this.

Thank you everyone.

 

[Wanebo]

SES is old. I think the final release of it was around 2011 and Avaya has a much better SIP routing engine and registrar in Session Manager. You should move up to that. That said...

No. Do not go direct CM to SIP service provider. You need to use an SBC between your network and the public network spaces. SES and Session Manager are not SBC's and provide little protection
against hackers and people who want to infiltrate your network. If you can't afford or don't want to afford an Avaya SBC there are some perfectly fine open source SBC platforms available to use.

CM is very domain centric and so is Session Manager. So are SBC's and SIP registrars. And for a good reason. SIP headers are very dependent upon correct domains for their routing and handling.

 

[kyle555]

The devconnect link seems dead.

The other link seems reasonable but I found it curious that they used public IPs on the Avaya gear. You always need a SBC to broker NAT. Even if port forwarding and static IP mapping works to get the SIP traffic going, if CM wants to setup a call to a phone on 192.168.1.2, that's what it'll put in the layer 7 SIP message. An SBC will rewrite that going out so the far end knows to send audio to the SBC.

Look real close at section 1

In addition, the Avaya Customer Premise Equipment (CPE) equipment is configured with public Internet IP addresses.

 

[edcelf]

Here are some of my configs, 208.74.75.251 is of SIP Provider.

 

[edcelf]

Correction on my Signalling group, I am using the IP-network-region 5 disregard the network region 4

 

[Wanebo]

Your near end and far end node names are he same. procr shouldn't be stuck talking to iteself. Near end could well be procr but the far end should be the ip of your SES if that's where the trunk will terminate.
Why is the near end port set to 6001?
Domain names should not be ip addresses. Trsomething like sip.yourcompanysname.com.

 

[edcelf]

@Wanebo, as stated on the Application Notes, for co-resident SES, near-end and far-end node should be the same. As for port 6001, it is the port used for the TLS Link between CM and co-resident SES (might as well non-co-resident SES), although we can change that but the Notes recommended the port 6001 (most commonly used).

Update on this, I have tried using TCP Link between CM and SES instead of TLS Link and I got another error of SIP 400 Cannot Route: No Basic License. Upon checking on the licenses, it is still active.

I'm really having a hard time with this, hope you can help or you know a TAC Engineer. Really appreciate your responses Sirs, Thank you!

 

[kyle555]

see my note above. the interop note you're following implies your CM and gateways and stuff have public IPs.

You need a SBC.

 

[janni78]

As Kyle555 said, you need a SBC.

The SIP provider need to be able to send SIP signaling to your SES and RTP to your MGWs.
Since you have all equipment on internal addresses those are what they will provide to the end-node so they will not be able to send anything back.
Also the PBX shouldn't use public IPs, dunno why Avaya ever made a app note doing that.

"Trying is the first step to failure..." - Homer

 

[edcelf]

Update on this.

I have configured a Direct SIP Trunking CM to SIP Provider, and the outgoing calls are okay but, incoming calls always get the denial event 1751: No AAR/ARS route pat/pref D1=0x83001f D2=0x1c001. Incoming call handling treatment is already configured, but still, I get the same error. Please help!

 

[kyle555]

Look at the invite coming in. It'll be @something. is it the same IP as the far end domain of the one you setup?

If not, build one.

If you got some router that's doing some SIP transforms to help you out, it might work, but man... even if you get it working, that ain't the right way to do it.