How to tell what PRI-t1 is used to link to remote voicemail 1

[RodneyMcSnow]

I have a client that has G600 Gateways in 2-cities. All of a sudden the remote site does not have access to the voicemail anymore instead all calls goto the operator at the main site, not voicemail.
I have access to the G600 but not familiar with tanslations. I know that their are 5-PRI-T1, how can I locate in programming the T1 Loop and see where it goes too?

Once again,. Im Avaya Blue Certified and Familiar bu the G600 Im only familiar with hardware. There is a computer on=-site and customer does have the passwords to the system.

 

[DAVIDPAYNE]

Do a list trace station on one of the extension at the remote site, and then dial that extension.
You should see where the calls is being denied after trying to cover to voice mail.

 

[RodneyMcSnow]

What are the mnemonics I need to enter to perform the list trace?

 

[lopes1211]

Well....if you did not say what vmail system but if flat out lost integration, you would likely get the generic audix greeting "please enter the extension you want". Getting the main operator would happen if the operator is the default zero out (likely) AND the Audix receives caller information that does not match a valid mailbox. Depending on the integration method, that could happen if someone was messing around with the private or public unknown numbering tables. Has anyone been trying to modify outbound calling-party-number/caller ID lately for the impacted location? If this was the case, admin logs in Audix would confirm and/or clue you in.

example - unknown numbering set to 4 digits. ext 1234 rolls to vmail, vmail receives 1234 info and routes call to mailbox 1234.

someone goofs around with the numbering tables and decides to send npa/nxx/ext. vmail receives 555-444-1234. Audix looks at the 1st 4 digits and puts an entry in the admin log saying "non-subscriber 5554" and sends the call to the operator.

.........just a hunch.

-CL

 

[montyzummer]

list trace station xxxx" is the command , run the command and press the message key on the phone , you will see what trunk is grabbed and then the delivery method into the VM.

What lopes is referring to is quite possibly your issue , when you have found the trunk for VM , issue the "display trunk x" command and around page 3 ish(not got a kit in front of me) you will see either a private or public statement in numbering format field.(this then determines if you need to check the public or private numbering table.

Have a look at the doc page 23 for an example of the trunk setting , then page 27 for the private numbering table(public same command with public in place of private).

When you have done all that come back and let us know if you are still struggling.The output from a list trace station from a station that does hit VM and one that doesn't will be really useful , so attach both of those to your post.

ACSS (UC/SBCE/SM/SME)

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

 

[montyzummer]

http://www.cisco.com/c/dam/en/us/so...nteroperability-portal/avaya-app-note-6-3.pdf

here is the doc i refer to the below link will also help although your integraton is different the logic is the same

https://www.devconnectprogram.com/fileMedia/download/9f0bd455-4705-4da5-8fcc-e4b7930086f3

ACSS (UC/SBCE/SM/SME)

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

 

[RodneyMcSnow]

So far, I haven't been to the site due to customer restrictions, but I do know that this started a few days ago when the local telco company moved a T1 circuit from one NIU Shelf to another NIU Shelf (bad NIU slot NIU cabinet).

According to the customer, thats when this all started. Not sure what else the Telco person has done.

Friday evening, the customer did have a technician goto the local site (Why, I dont know) where voicemail is hosted (not sure of make/model) but the technician then walked the customer through some list trace commands on the remote site and informed the customer that the calls are routing out trunk group 10 instead of 2.
My guess is that someone moved T1 cables around.

Im going to see if there is routing set-up when the point-to-point T1 is down to re-route the point-to-point calls and overflow to the Long Distance T1.

Hopefully, will get on-site today and keep all posted.

 

[RodneyMcSnow]

Good morning all,

Last night I was able to gain entry on-site and performed a "list trace station xxxx" command , pressed the message key on the phone and noticed that the system was unable to grab trunk group 99 due to it being out of service therefore preventing callers from going to VM.

I also listed the Trunk Groups and noticed that local 4-digit calls to the main site were overflowing across the local T1 Trunk Group.

Long story short, the customer informed me that there happened to be 4-diiferent Telco Techs onsite last week and they were moving T1 Circuits around. I finally identified the local, log distance and point-to-point circuits on the NIU Shelfs.

I then re-connected the T1s to their respective cards so that local goes to local circuit, long distance to long distance circuit and point-to-point to point-to-point circuit and now all dialing patterns are functioning as intended and the calls are routing across the T1s and 4-digit dialing is working along with access to Audix VM.

Thank you all whom chimed in and the documentation. All were a valuable resource to getting into the system and moving around in programming.