Inbound EC500 not converting to Internal Extension

[SouthernKnight]

We recently started moving some of our voice circuits from Verizon to Lumen. All of that itself is going fine. However, since we have moved we have noticed an oddity...

In the past, on the Verizon circuits, if a user with EC500 calls their own DID it would convert the inbound EC500 number to their internal extension. This would then drop them into their voicemail (Avaya Messaging) automatically (prompting for password), so that they could check their messages.

Since converting some of our offices to Lumen though, this is no longer working. The call rings at the extension and then goes onto coverage which then sends the call to voicemail as if they were a regular caller trying to contact them.

EC500 still works fine on outbound calls over Lumen, just as it did over Verizon.

Also, our normal Avaya Messaging pilot number, which is on Windstream (yes, I know...a 3rd circuit vendor), operate fine when someone calls it. In other words, it drops them into their mailbox and asks for their password.

The trace shows what is happening...the number is not being converted from the inbound CallerID to the associated extension for EC500. However, I am at a loss to see what to change. Lumen is sending 10 digits, just as Verizon and Windstream do. Is it perhaps something I am missing in the Configuration-Set?

Any help is greatly appreciated.

 

[ZeroZeroOne]

Sometimes the external number is programmed as 11-digits, which works fine for dialing out. If the provider is sending 10-digits, you will probably have to edit the number and only put 10-digits in the number and the "1" in the Dial Prefix column.



Next is to check the incoming call handling for the new trunk and see if there's anything different there compared to your other trunks.

 

[SouthernKnight]

001,

I have moved that 1 everywhere lol. Put in dial prefix, put it in the phone number, left it off. Sadly same results.

Incoming call handling is the same as it was prior to moving to Lumen. I've also tried a few things there as well, such as in case it was getting 11 digits to strip 1 off, and conversely if it is 10 digits to add 1.

 

[ZeroZeroOne]

Hmm...

Assuming these are PRI, did you create new trunks in CM for Lumen or did you unplug your existing circuits from Verizon and just swing the cables over to Lumen?

If new trunk programming, do the patented Stare and Compare^TM method between the Verizon trunks and Lumen. Double check DS1s and Signaling Groups, too. This is especially important since calling the VM pilot number over Windstream works correctly.
If you are reusing the Verizon programming and plugged Lumen directly in, the problem may be with the carrier since the programming did not change. Not sure what that would be, but if one worked and the other doesn't then follow the trouble.

Even if they were SIP trunks and you had a domain fat-fingered somewhere (such as on the IP-Network-Region), CM should still be able to match the inbound Caller ID to the Off-PBX Station-Mapping.

Perhaps you can run "list trace tac [inbound CLID]/c" for the caller ID of a station with EC500.

Using my previous example, Mobile number 617-289-0101 is mapped to station 123456 (DID 617-289-3456). Normally, when the Mobile calls any DID on the PBX, the Inbound CallerID is matched to station 123456 and the receiving station sees the information for station 123456. I'd trace out both calls to other DIDs as well as to the user's own DID. Both should map correctly.

User Mobile calling User DID - Does voicemail recognize the User and go directly to the mailbox or does it go to "generic" greeting?
User Mobile calling OTHER DID - Does the Other user see Station name and number or the outside CLID?
I would think the results should be the same - either both see the Mobile CLID or both see the mapped station.

I hate to ask about the incoming call handling again, but please make sure the trunk groups include the Lumen trunk. If your Verizon was trunk 1 and you added Lumen as trunk 20, the incoming call handling should either be blank to apply to all trunks or you need to specify which trunks will use that rule.

While not common, it's possible to use the unified dial plan to convert numbers instead of the incoming call handling.
I've also seen systems where calls are inbound on PRI, routed to Session Manager for the sole purpose of changing the dial string, then routing back to CM. Customer was using this as a workaround to allow short-code dialing in locations instead of the AAR digit conversion. Drove me nuts to see 10 million trunks (I exaggerate only slightly) in that system. Anyway, I'm getting into the weeds on this, trying to think of various ways the dial string can be manipulated.

 

[Bill P]

Did you convert to SIP trunks? If so you probably need to change the setting on page 2 of the station form Per Station - Send Calling Number and Name? to yes. It defaults to no.

 

[Bill P]

Keep in mind that even when you get what appears to be a traditional PRI, they are most likely SIP on the back end...so you can still have SIP type issues.

 

[Bill P]

Also, is the trunk set to public or private? And do you use the calltype analysis table? And I'm assuming the DIDs got moved over to the new trunk?

 

[SouthernKnight]

After finally getting an Avaya SME to do a MST trace we may have the solution.

I'll write it up and post it after Lumen makes some changes and I verify it.

 

[SouthernKnight]

So the issue is still not resolved BUT we do know what is causing it.

The MST trace showed us that the screening attribute was not/is not being sent with the call data from Lumen. At this particular site we are testing with we have one of their older Adtran devices performing the SIP to PRI handoff. The Adtran does not appear to be able to address this attribute on calls.

We are waiting to see if their Cisco (4490 I believe) devices have the ability to turn on the screening attribute.

We are able to force the call to bypass this by having Calling Number Verification? n set in the off-pbx-telephone configuration-set that the EC500 entry is using.



However, this is not a solution at all because the possibility of opening us up for toll fraud is raised signifigantly.

I'll respond again once Lumen lets me know about their Cisco devices.