I have a client running a NV7100 for 5 locations here in town. Some of those locations are in the 216 area code, and others in the 440 area code. They all ultimately call out using the same PRI that is connected to a TA 904 local to the NV7100. I need to send 10 digits to the carrier, so I am replacing Nxx-xxxx with 216-nxx-xxxx. The problem arrives that the users in the 440 area code want to dial 7 digits and "be in" the 440 area code. I am not sure how to accomplish this. I do have TA908e's at the remote sites set up as transparent proxies for failover and 911 calls. I don't know if that can help or not, because I am not sure if the proxy has the ability to modify digits being sent. These are VVX410 and VVX500 phones running 4.1.6 software, the 7100 is running R10.11.0E and the TA908e's are running R10.9.1.
Thanks
Andrew
Andrew,
Can you explain a little bit more on your topology. How does your 7100 connect to the PSTN?
Is it like this
7100------Eth------TA904-----PRI-----PSTN
does the 7100 have any other PSTN connections?
The main question is for the users with the 216 area code, what is the office code? What is the XXX in this 216-XXX-0000?
And the same for the 440 area code, what is the office code?
If they are different then you can create rules to apply the appropriate area code based on the office code.
Regarding the remote sites with the TA908e's, I assume you have local PSTN connections there also?
When the remote TA908e's are in failover mode using SIP transparent proxy, the switchboard takes over and then routes the call out the analog/pri trunk to the PSTN, then it will use the accept numbers in the trunk group, you can therefore use match ani rules to modify the ANI before the call goes out to the PSTN.
This application is something we are adding to our new ATSE/UCAS class which goes over 7100 at main site and has NV6355 and TA908e at remote sites and goes over Least Cost Routing (LCR) using Sourced Ani Based Routing (SABR) and using SIP Transparent Proxy. Sounds like you are doing much of that. That class is scheduled to be released around May. The labs in it are awesome.
Let me know what you have and I can help you out.
-Mark
Message was edited by: matt - added links to documents
Anybody have any ideas?
Andrew,
Can you explain a little bit more on your topology. How does your 7100 connect to the PSTN?
Is it like this
7100------Eth------TA904-----PRI-----PSTN
does the 7100 have any other PSTN connections?
The main question is for the users with the 216 area code, what is the office code? What is the XXX in this 216-XXX-0000?
And the same for the 440 area code, what is the office code?
If they are different then you can create rules to apply the appropriate area code based on the office code.
Regarding the remote sites with the TA908e's, I assume you have local PSTN connections there also?
When the remote TA908e's are in failover mode using SIP transparent proxy, the switchboard takes over and then routes the call out the analog/pri trunk to the PSTN, then it will use the accept numbers in the trunk group, you can therefore use match ani rules to modify the ANI before the call goes out to the PSTN.
This application is something we are adding to our new ATSE/UCAS class which goes over 7100 at main site and has NV6355 and TA908e at remote sites and goes over Least Cost Routing (LCR) using Sourced Ani Based Routing (SABR) and using SIP Transparent Proxy. Sounds like you are doing much of that. That class is scheduled to be released around May. The labs in it are awesome.
Let me know what you have and I can help you out.
-Mark
Message was edited by: matt - added links to documents
You are correct in how the 7100 connects to the PSTN. The 7100 only has the one SIP trunk to the TA that ultimately reaches the PSTN. Every user in they system has a DID, most of which are in the correct area code for the site.
The TA 908e's have only one loop start trunk for Emergency(911) and as a single failover if the VPN to the main site goes down, and the PRI cannot be reached.
I see you opened a ticket for this. It would be best to continue to work with ADTRAN Pre-Sales Support on this through the ticket. Once you have a solution please come back to update this thread so others can benefit from it.
Thanks,
Matt