I need to configure a 904 to keep calls from one FXS port to another FXS port on the same system internal. AOS 10.7.0
Trunk t02 type SIP
!Working Sip Config
voice forward-mode local
Voice User 555-1234
connect FXS 0/1
Voice User 555-9876
connect FXS 0/2
voice grouped-trunk SIP
accept $ cost 0
555-1234 goes off hook and dials 555-9876 currently call is sent out SIP Trunk hits upstream provider and then call comes back down stream.
Anyone have any ideas on how to do the call routing to keep the call local if the to number is local to the system?
555-1234 goes off hook and dials 555-9876 call never goes out SIP trunk and stays on the local 904
Configuring a specific reject for the local fax numbers on the SIP grouped-trunk still won't cause a problem.
That will prevent calls to those specific numbers from leaving out the SIP trunk. It won't affect incoming calls to those numbers from the SIP trunk.
Seeing as those phone numbers are local FXS users, there is no reason to send calls from the Adtran out the SIP trunk for them. As you've discovered, they'll just hairpin back anyway. So reject them specifically on the SIP trunk and they'll stay local.
This should stay local.
Are both the stations 7-digit and the local calling pattern is also 7-digit?
Did you try it without the hyphen? "voice user 5551234" instead of "voice user 555-1234"?
You might need an alias to sort out the dial plan, for example if the SIP trunk sends 10-digits and you want a 7-digit (or 4-digit extension) local connection. For example:
voice user 3125551234
connect fxs 0/1
Try "debug voice verbose" and make a local call, paste the result as well as the configuration sanitized of passwords.
The system would not accept the alias command, i am guessing because the alias and the number where an exact match already I was able to set the DID. In the actual config there is no hyphen I had put that in the sample for readability. In this case all the calls are 10 digit dials. Working on capturing the debug now will post once I have it. Can you or some else verify if it takes a reboot for voice forward-mode local to go into affect. I did change it as originally it was network but changed it to local for this issue.
voice forward-mode local has to do with how call-forwarding is handled, not call routing. This shouldn't affect the scenario you describe.
I'm somewhat confused as your sample config showed 7-digits as the voice user and above you state "In this case all the calls are 10 digit dials."
For a call to be handled locally the following three things have to match:
Thanks for the reply. I just put in a sample config not the actual config in example thats why it shows 7 digits but here are the excerpts from the actual config based on the three areas you mention with scrubbed NPA-NXX and passwords, in this specific example there is a fax machine at NXXNXX2115 dialing NXXNXX2120 the call goes out the SIP trunk hits the SIP Provider switch is then sent back down the SIP trunk back to the other voice user this is evidenced by two entries in the Call Quality Status with the same From and To number in both which is how I first noticed the calls where not staying local on the Adtran. If it where a voice user misconfiguration I would not expect to see the call come back and connect. The end user was gone for the day so I was not able to capture the debug yet, I will work on getting that tomorrow. I have not seen this problem previously but this is the first time I am doing FXS ports on 10.7 code, all previous Analog deployments had beed on 4.X code.:
voice dial-plan 1 local NXX-NXX-XXXX
voice dial-plan 2 long-distance 1-NXX-NXX-XXXX
voice dial-plan 3 toll-free 1-8XX-NXX-XXXX
voice dial-plan 4 international 011-$
voice codec-list fax
voice user NXXNXX2115
connect fxs 0/3
rtp packet-delay fax 150
voice user NXXNXX2120
connect fxs 0/4
rtp packet-delay fax 150
This should just work, but I'm curious as to why you have did "NXXNXX2120" in the user configuration. This shouldn't be needed unless you're passing digits to the extension and it may be causing the failure. I would no that out and retry. Debug voice verbose will be helpful.
I wouldn't think it necessary, but if all else fails try adding the actual extension numbers to the dial plan as extensions.
voice dial-plan 5 extensions NXX-NXX-2115
voice dial-plan 6 extensions NXX-NXX-2120
When entering these use the actual digits, not NXX-NXX.
Originally the did statements where not there. When I tried to add the alias command as you recommended trying the system would not take the command, so I tried did in place of alias and it took the command. I will try the extensions in the dial plan that does make sense that way the switchboard knows those numbers are local to the Adtran itself.
OK, the alias is needed if the phone needs to ring with two or more different dial patterns, for example if your area is set up for 7-digit local calls and the SIP provider sends you 10-digits to ring the same FXS port you would use the alias of 7-digits to handle the locally dialed calls. Same if you have 3- or 4-digit extensions you want to keep local.
Sometimes you want to have the call hairpin through the provider. For instance if you have a hosted PBX with centralized voice mail offsite you wouldn't be able to leave a message if it stayed local. SABR will handle that case.
Debug voice verbose should give us a better handle on it.
Added the extensions to the dial plan using the full actual numbers. Problem is still occurring. Got a copy of the de voice verb got to scrub it. I am seeing the SSwitchboard is matching on NXX-NXX-XXXX rule on sip trunk group and not going any further. I will get it scrubbed and posted shortly.
Added the extensions to the dial plan using the full actual numbers. Problem is still occurring. Got a copy of the de voice verb got to scrub it but what I did see is the call is connecting to the SIP trunk as soon as it goes of hook before it even starts collecting digits. I will get it scrubbed and posted shortly.
Really? What does the destination string in the SIP INVITE look like?
What does the grouped-trunk that includes the SIP trunk look like? If you just go off-hook and don't dial anything does the dial tone go away after three seconds or so? From your description it sounds almost like there's a hotline auto-ringdown programmed or the SIP trunk is accepting an empty string.
How about posting the config scrubbed of passwords as well as the debug voice verbose. Let us know for the debug what station attempted to dial what string.