Adtran 7100 at main office and 6135 at remote office

[Anonymous]

Hi, I have a customer with a 7100 at main office with PRI. (210) Area codes

Remote office has 6135 with 4 analog lines at the remote office.  (956) area codes.

Both office do 9 plus 7 digit dialing.

The needs to call forward the analog line (956) to a local 956 phone numbers, however I want to force to go go through the PRI.

I'm having a very hard time doing this.  We are using the call forward features.

So currently that analog line is terminated into a make up DID lets say 8000.  It then goes through the point to point sip to the phone system.  Then goes to an extension at the remote office which is tie to the main office via a point to point between the two office.

I'm guessing when we call forward and try to tell it to dial 919567777777, its trying to go out the 4 analog line.

anyone have a way to force it to go through the PRI?

[Anonymous]

Could you supply the configurations for both of these units? You can use the instructions below to put them on our FTP server in a .zip file:

Open Internet Explorer web browser on their PC
Type the following URL:  ftp://ftp.adtran.com

Press the Alt key, click View, and then click Open FTP Site in Windows Explorer

Double-click the "Incoming" folder
Drag and drop files from PC into the Internet Explorer window

Reply to this post with the exact filename used so we can retrieve the files

Also, can you walk me through all the steps you are using to attempt to forward the line now?

Thanks,

Matt

[Anonymous]

The file is call 7100.cfg and 6355.cfg.  Right now, customer is just dial 72 which automatic pickup a line, then they dial the call forward number they want to.  I want to use the Http://192.168.2 1.80

extension 8016

password

then call forward all calls to the answering service.

Hope that make sense...

The problem with the current setting is with ATT, they will only call forward calls to the main number, not the roll over numbers.

We have two options, give them a way to pickup line 1, 2, 3, 4 directly on the 6355 so they can call forward.

Or Allow the calls on 1,2,3,4 (956 area code) from the 6355 to be able to route through the 7100 T1/PRI (210) area code.

Both sites currently use 7 digit dialing.  9 NXX- XXXX

So for call forwarding to work - Analog line  (956) - goes through network sip trunks - then out pri as LD - 91 - 956 - xxx - xxxx (ANSWERING SERVICE PHONE NUMBER).

[Anonymous]

Thank you for supplying the configurations.  You may want to try this after hours to confirm it works first, but after looking at the setup this is an option that may work:

• create a new virtual user for the McAllen receptionist phone
• remove the DIDs from voice user 8016 and relocate them to the new virtual user extension
• have the virtual user always coverage immediately to 8016
• edit the SanAnt_Users ani-list used with SABR to include the new virtual user extension so calls sourced from it can go out the PRI
• log in the personal phone as the new virtual user and attempt to setup the call forward

The existing method to forward calls via using *72 from McAllen to shortcut out the FXO trunks should still work as well in case that is still needed.

Thanks,
Matt

[Anonymous]

Thanks Matt, I've tried this once before, however, I did not do this.

edit the SanAnt_Users ani-list used with SABR to include the new virtual user extension so calls sourced from it can go out the PRI

Can you show me specifically how do I go about edit the SanAnt_Users ani-list used with SABR?

[Anonymous]

SABR is used to route calls based on their source.  Here is a link to our SABR guide: Source and ANI Based Routing in AOS Voice Products.  This is implemented in your configuration to route calls from the proxy phones at the 6355 site out the analog lines local to that site.  It is also used to ensure the phones at the 7100 site have their calls routed out the PRI local to that site.

To edit an ani-list you just need to get in the configuration mode for the list and specify the extension to add with the ani xxxx command, where xxxx is the extension.  For example if you picked 8020 for the new virtual extension you could add it to the ani-list with these commands from global configuration mode:

!

voice ani-list SanAnt_Users

ani 8020

!

Thanks,

Matt

[Anonymous]

Hi Matt, I've did that and tested it, but no luck.  Can you help me out?  Below is the call log  via debug voice verbose.

---output removed--

Message was edited by: matt - removed debug with public phone numbers

[Anonymous]

Can you upload the current configuration and the output from both a debug sip stack messages and debug voice verbose enabled at the same time to the FTP server?

Thanks,

Matt

[Anonymous]

The file is call callforward.txt, sa7100.cfg, McAllen6335.cfg.

I've call forward and tested twice.

First call forward to 91956213xxxx

Second call forward to 9956213xxxx

Thanks

[Anonymous]

In the configuration I see an override mode coverage to the external number for x8016 instead of a call forward set on the new virtual user (x8015).   I was not sure if the configuration I had on file was the same from when the test was performed, so I wanted to check.  If so, can you try setting a call forward under 8015 to see if that works? 

Thanks,

Matt

[Anonymous]

I did call forward using extension 8015 via webrower.  I think it does call forward, then I'm getting a message it is not necessary to dial a 1 or 0 when dialing this number.  Sounds like it still route out the 956 (McAllen number).  I don't know, I'll call into tech support tomorrow.

[Anonymous]

I saw that you opened a support ticket for this.  Once you reach a resolution from it, please come back to this post to update it with the solution so others can benefit from it.

Thanks,

Matt

[Anonymous · Accepted solution]

It looks like the root of this problem was the caller-id on the forwarded calls, which were not matching the ani-list.  This was fixed by modifying the ani-list to permit all ANI out the PRI while still denying specific numbers from the other remote site.  If I got any details wrong or if you can think of any other helpful information to add to this post, please come back to update it.

Thanks,

Matt