SIP Configuration Changes in 11.0.4.4?

[1ntegrationman]

Trying to find the issue with my inbound SIP calls on a IP500v2 running 11.0.4.4.

We have over 50 systems connected with this SIP carrier, and have triple checked that our settings are the same (or close to the same when considering version variables).

Outbound calling works great, but with inbound calls we keep getting the error in System Status that "The following line had no Incoming Route for a call. Line xx / Line Group ID xx / DDI: 1xxxxxxxxxx .

I am confident that the firewall has the appropriate ports open... in fact for the purpose of testing the Firewall tech opens port UDP and TCP port 5060 traffic from any server, and Media ports from any server. He shuts them back down after testing, but I thought it worth mentioning.

Any help would be appreciated.

 

[sizbut]

The following line had no Incoming Route for a call. Line xx / Line Group ID xx / DDI: 1xxxxxxxxxx" seems a pretty clear warning message. Have you checked?

That would also imply that calls are getting to the IP Office (just don't have anywhere to go). So its nothing to do with ports, firewalls, etc.

On the SIP line, what are the incoming group ID settings of the SIP URIs? Do these have a matching Incoming Call Route with the same Group ID and a destination set?

Stuck in a never ending cycle of file copying.

 

[1ntegrationman]

Thanks for your response sizbut. And yes, the error is clear. And I have the URI built with trunk numbers assigned, and the Incoming call route has the phone number entered accurately with the correct Line ID assigned to it. Tha't the challenge. The error is presenting a problem with programming that is already built in the system.

One of the things the distributor suggested this morning was deleting my SIP trunks, rebooting and building them fresh. Now that we are stepping outside of business hours I will try that.

But I opened a ticket with Avaya and they were not willing to help... stating that there was a configuration issue and knowing that this was the first SIP trunk on this newly upgraded ayatem they were there to help fix something that used to work but has since broken... And the fact that they were so confident that there was a configuration issue led me to continue the search through documentation to try to figure out if Avaya changed something in 11.0.4.4 specific to SIP URIs and Incoming call routing.

 

[derfloh]

If you want to use incoming call routing you have to set auto/auto/auto in your URI settings for inbound calls.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[sizbut]

Start with an ICR that routes just on the line group ID, don't put anything in the CLI and number fields. If that works, then move on to trying to match the incoming number.

Stuck in a never ending cycle of file copying.

 

[sizbut]

ps. You can have multiple ICRs, one that matches anything on the line and one that mmatches the line and (hopefully) DDI. That gives you a safety net of default incoming call routing for the line for when the system can only match on the line number.

Stuck in a never ending cycle of file copying.

 

[1ntegrationman]

Thanks for all of your responses. I believe I found the issue. Found in the Incoming Call Routes / Default Blank Call Routes in the Knowledgebase.

By default the configuration contains two incoming calls routes; one set for Any Voice calls (including analog modem) and one for Any Data calls. While the destination of these default routes can be changed, it is strongly recommended that the default routes are not deleted.

Deleting the default call routes, may cause busy tone to be returned to any incoming external call that does not match any incoming call route.

The system had a default "Any Calls" incoming call route built for the current PRI, so I added a Blank "Any Calls" and "Any Data" call routes with my SIP Trunk number and the calls started routing.

I did end up deleting the trunks, rebooting the system, rebuilding the trunks, rebooting the system and it did not correct the issue. So I've learned that these Blank voice and data routes are (I believe) an essential part of call routing for SIP calls in 11.0.4.4.