Inbound calls not following coverage

[gordopa1]

We have run into an odd situation with one of our physician practices that we have recently moved onto our Avaya CM 6.3 (R016x.03.0.124.0) system. The practice's old main number was forwarded (long distance) to a DID on our CM. That DID is set up as a VDN and gives a menu with a few options and has time of day logic. Some of the menu options ring individual phones that are programmed to cover to messaging after 6 rings. If our DID VDN is dialed directly, this all works perfectly. If the forwarded number is dialed and the caller chooses an option that routes to an individual phone extension, the call never follows coverage. The phone just continues to ring as if no coverage points are defined.

Has anyone run into a situation like this before? Any tips on how to troubleshoot? Please let me know if I can provide any more specific info.

Thanks!

 

[wpetilli]

Where is the old main number being controlled from? Sounds like double coverage, but would need to see traces.

 

[gordopa1]

Where is the old main number being controlled from? Sounds like double coverage, but would need to see traces.

The practice's old main number still routes into the Nortel BCM that they have at their site. The BCM is set to turn it right back around and send the call to our local DID. We have begun the process with CenturyLink to have their main number removed from the PRI that runs into the BCM and have it forwarded at the telco, but it has not been a smooth process thus far.

 

[AvayaTier3]

check your vector for
route to steps with cov y

use list trace vdn or list trace vector to trace the call

A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"

bsh

40 years Bell, AT&T, Lucent, Avaya
Tier 3 for 30 years and counting
[URL unfurl="true"]http://bshtele.com[/url]

 

[gordopa1]

check your vector for
route to steps with cov y

use list trace vdn or list trace vector to trace the call

All coverage options are set correctly, these calls work as expected when the local DID is dialed directly. The list trace vec shows no abnormalities, but it ends as soon the call is routed to the phone with a 'Leaving Vector Processing" message.

Working on pulling some TraceSM logs now if that would be helpful.

 

[montyzummer]

Run a list trace on the station that the call ends up on , traceSM will not give you anything beneficial in this instance , i know you are saying that coverage options are set correctly but this does sound like a statement in the vector that is not quite correct , (that said if you are 100% that both numbers are actually tied together and they both hit the same VDN and vector this is indeed a wierd one ... are you sure that my last statement is the case ?is it possible the OLD number actually hits the system at a different entry point , whilst appearing to hit the DID that points to the VDN)

As i say run a list trace on the station the recieves the call , if you can post a good and bad trace that would be helpful , also can you lay out the incomming route in programming terms from entry point to phone , so incomming treatment table x , vdn xxx , vector x etc etc , then run a "list usage digit string XXXXXXXXXX" where XXXXXXXX = the old number , just to make sure nothing is actually intercepting in CM thats not obvious.

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.

 

[gordopa1]

is it possible the OLD number actually hits the system at a different entry point , whilst appearing to hit the DID that points to the VDN

We are a 7 digit switch, thus our DID is the VDN. My traceSM logs show a connected call between my cell phone and our VDN DID when dialing the forwarded practice number, and I did verify that the number is forwarded directly to our DID.

In both scenarios, a call comes in through Verizon as SIP through one of our two SBCs. From there, the call is routed to SM and then passed to CM. CM then takes VDN 8127559 and passes it to vector 1036.

I have included screen grabs of good and bad traces, the vector, the station, and the coverage path in this album.

 

[kyle555]

I wonder if trk-to-trk xfer override is on and/or if the incoming trunk COR or VDN COR come into play.

I wonder if as a test, instead of the old number CFWD to a DID that hits a VDN instead goes right to a station, will it cover to voicemail then?

 

[gordopa1]

I wonder if as a test, instead of the old number CFWD to a DID that hits a VDN instead goes right to a station, will it cover to voicemail then?

Just deleted the VDN and built it as a station with coverage to VM after 2 rings. Call from my cell phone to the forwarded number rang desk phone twice and then successfully went to VM.

 

[kyle555]

VDN cor vs station cor?

 

[gordopa1]

VDN cor vs station cor?

The CORs are different, but the differences would not play into this in my opinion. The station COR cannot be service observed while the VDN can, the station COR does not Block Enhanced Call Pickup Alerting and the VDN does do that. Those appear to be the only differences I can see between the two CORs.

I appreciate everyone's suggestions thus far.

 

[montyzummer]

OK so the failed trace shows the call comming in on a trunk group 905 , the failed trace shows it as a direct ststion to station calll

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.

 

[montyzummer]

Can you status station 8127525 and show pages 1,2 as the call forwarding in the trace im pretty sure (dont have a kit infront of me to test) should not follow the coverage statement , it just doesnt look correct ... i may be wrong but i would expect the coverage option to hit h900(im guessing your VM hunt group) not dial #608(TAC CODE?) THEN 517700

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.

 

[kyle555]

and, why is the VM hunt in the coverage path 1 rng only? Should be blank to "ring forever" to voicemail

 

[montyzummer]

Sorry failed comming in on trunk 905 good trace station to station

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.

 

[gordopa1]

OK so the failed trace shows the call comming in on a trunk group 905 , the failed trace shows it as a direct ststion to station calll

This is because when i was capturing the traces I was calling from a station. I have recreated the traces in the new album linked here with both calls originating from off switch. Now both calls are coming in on trunk group 904, which is our primary inbound SBC.

Can you status station 8127525 and show pages 1,2 as the call forwarding in the trace im pretty sure (dont have a kit infront of me to test) should not follow the coverage statement , it just doesnt look correct ... i may be wrong but i would expect the coverage option to hit h900(im guessing your VM hunt group) not dial #608(TAC CODE?) THEN 517700

The status station screen caps are in the album linked above. #60 is programmed in our system as a FAC for AAR Access Code. The 8517700 is the pilot to our voicemail system. You are correct that h900 is our hunt group for messaging.

and, why is the VM hunt in the coverage path 1 rng only? Should be blank to "ring forever" to voicemail

That was a change I made while troubleshooting. It was originally set to blank. In testing, I found that setting the 8127525 station to cover path 1 sent the call to VM successfully, and cover path 1 has that ring 1 in for h900. Cover 1 is built in our system to send all calls straight to VM. I have also included in the album a call to the forwarded number with the station 8127525 set to cover path 1. This call successfully went to VM. A screen cap of cover path 1 is included for reference.


Just to note: Due to having issues, I was able to get a to a higher level support with CenturyLink and the remote number is now forwarded at the telco, not in the practice's BCM. Unfortunately, the end results are still the same. The traces in the album from this post are with the telco forwarding in place.

 

[kyle555]

I don't think this is exactly your problem, but once upon a time on AAM 6.2, I had a problem where calls would follow coverage but AAM would never answer.

call to a SIP DID in my switch to a station to voicemail - fine
Call to another carrier's DID CFWD at the CO to a SIP DID in my switch to a station - fine. To voicemail - never answered.

Turns out one carrier to the other was sip and part of a diversion header had a ; instead of a , or a : and while legal, AAM 6.2 never answered.


What do the full invite messages look like coming in on the SBC/SM when each # is called? Time to stare and compare