Support
Community

Anonymous · ‎08-20-2013

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

Sample Config:

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

trunk t02

accept $ cost 0

Scenario:

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?

Desired:

555-1234 goes off hook and dials 555-9876 call never goes out SIP trunk and stays on the local 904

jayh · ‎08-28-2013

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.

View solution in original post

jayh · ‎08-21-2013

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

alias 5551234

alias 1234

connect fxs 0/1

...etc.

Try "debug voice verbose" and make a local call, paste the result as well as the configuration sanitized of passwords.

Anonymous · ‎08-21-2013

jayh,

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.

John Wable

jayh · ‎08-21-2013

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:

Voice user digit string (and/or alias)
Exactly what is dialed by the caller
Matching dial-plan entry under "voice dial-plan" such as: "voice dial-plan 1 local NXX-XXXX" for 7-digit or "voice dial-plan 1 local NXX-NXX-XXXX" for ten-digit.

Anonymous · ‎08-21-2013

jayh,

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

default

codec g711ulaw

voice user NXXNXX2115

connect fxs 0/3

no call-waiting

did "NXXNXX2115"

modem-passthrough

no echo-cancellation

rtp packet-delay fax 150

codec-list fax

voice user NXXNXX2120

connect fxs 0/4

no call-waiting

did "NXXNXX2120"

modem-passthrough

rtp packet-delay fax 150

codec-list fax

jayh · ‎08-21-2013

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.

Anonymous · ‎08-21-2013

jayh,

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.

jayh · ‎08-21-2013

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.

Anonymous · ‎08-26-2013

jayh,

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.

John Wable

jayh · ‎08-26-2013

jwable wrote:

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.

Anonymous · ‎08-26-2013

Debug Voice Verbose

11:41:57.954 PM.0:2 Idle Processed OFFHOOK

11:41:57.955 PM.0:2 State change >> Idle->Requesting Dialtone

11:41:57.956 SA.5558542245 Ca:0 Idle rcvd: AcctPhoneMgr_appearance(ON) from PM

11:41:57.956 SA.5558542245 Ca:0 Idle State change >> Idle->DigitGathering (CAS_ReqDigits)

11:41:57.957 SA.5558542245 Ca:0 DigitGathering sent: AcctPhoneMgr_cachg(CAS_ReqDigits) to PM

11:41:57.957 PM.0:2 Requesting Dialtone CACHG:ReqDigits on primary CA

11:41:57.958 PM.0:2 State change >> Requesting Dialtone->SendingDigits

11:41:57.961 TONESERVICES.EVENTS fxs 0/2 - empty - Tone Detection: Request resource

11:41:57.961 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: DSP channel allocated for the resource

11:41:57.962 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: constructed

11:41:57.963 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: starting

11:41:57.963 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: TDM map

11:41:58.462 TONESERVICES.EVENTS fxs 0/2 - empty - DialTone Generation: Request resource

11:41:58.463 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - DialTone Generation: DSP channel allocated for the resource

11:41:58.463 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - DialTone Generation: constructed

11:41:58.464 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - DialTone Generation: starting

11:41:58.465 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - DialTone Generation: TDM map

11:42:00.628 PM.0:2 SendingDigits Digit 7 processed

11:42:00.629 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: received digit (5) event

11:42:00.630 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - DialTone Generation: stopping

11:42:00.630 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - DialTone Generation: TDM unmap

11:42:00.631 RTP.CHANNEL fxs 0/2 - dsp 0/1.1 - DialTone Generation: releasing RTP resource

11:42:00.632 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - DialTone Generation: release

11:42:00.632 SA.5558542245 Ca:0 DigitGathering rcvd: AcctPhoneMgr_dialDigit(5) from PM

11:42:00.633 SA.5558542245 Ca:0 DigitGathering Named-digit-timeout waiting 0 seconds for more digits

11:42:00.837 PM.0:2 SendingDigits Digit 0 processed

11:42:00.839 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: received digit (5) event

11:42:00.839 SA.5558542245 Ca:0 DigitGathering rcvd: AcctPhoneMgr_dialDigit(5) from PM

11:42:00.840 SA.5558542245 Ca:0 DigitGathering Named-digit-timeout waiting 0 seconds for more digits

11:42:01.027 PM.0:2 SendingDigits Digit 6 processed

11:42:01.028 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: received digit (5) event

11:42:01.029 SA.5558542245 Ca:0 DigitGathering rcvd: AcctPhoneMgr_dialDigit(5) from PM

11:42:01.029 SA.5558542245 Ca:0 DigitGathering Named-digit-timeout waiting 0 seconds for more digits

11:42:01.227 PM.0:2 SendingDigits Digit 3 processed

11:42:01.228 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: received digit (3) event

11:42:01.229 SA.5558542245 Ca:0 DigitGathering rcvd: AcctPhoneMgr_dialDigit(3) from PM

11:42:01.229 SA.5558542245 Ca:0 DigitGathering Named-digit-timeout waiting 0 seconds for more digits

11:42:01.437 PM.0:2 SendingDigits Digit 9 processed

11:42:01.439 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: received digit (9) event

11:42:01.439 SA.5558542245 Ca:0 DigitGathering rcvd: AcctPhoneMgr_dialDigit(9) from PM

11:42:01.440 SA.5558542245 Ca:0 DigitGathering Named-digit-timeout waiting 0 seconds for more digits

11:42:01.637 PM.0:2 SendingDigits Digit 6 processed

11:42:01.639 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: received digit (6) event

11:42:01.639 SA.5558542245 Ca:0 DigitGathering rcvd: AcctPhoneMgr_dialDigit(6) from PM

11:42:01.640 SA.5558542245 Ca:0 DigitGathering Named-digit-timeout waiting 0 seconds for more digits

11:42:01.837 PM.0:2 SendingDigits Digit 2 processed

11:42:01.839 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: received digit (2) event

11:42:01.839 SA.5558542245 Ca:0 DigitGathering rcvd: AcctPhoneMgr_dialDigit(2) from PM

11:42:01.840 SA.5558542245 Ca:0 DigitGathering Named-digit-timeout waiting 0 seconds for more digits

11:42:02.047 PM.0:2 SendingDigits Digit 1 processed

11:42:02.048 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: received digit (1) event

11:42:02.049 SA.5558542245 Ca:0 DigitGathering rcvd: AcctPhoneMgr_dialDigit(1) from PM

11:42:02.050 SA.5558542245 Ca:0 DigitGathering Named-digit-timeout waiting 0 seconds for more digits

11:42:02.248 PM.0:2 SendingDigits Digit 2 processed

11:42:02.248 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: received digit (2) event

11:42:02.249 SA.5558542245 Ca:0 DigitGathering rcvd: AcctPhoneMgr_dialDigit(2) from PM

11:42:02.250 SA.5558542245 Ca:0 DigitGathering Named-digit-timeout waiting 0 seconds for more digits

11:42:02.448 PM.0:2 SendingDigits Digit 0 processed

11:42:02.448 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: received digit (0) event

11:42:02.449 SA.5558542245 Ca:0 DigitGathering rcvd: AcctPhoneMgr_dialDigit(0) from PM

11:42:02.450 SA.5558542245 Ca:0 DigitGathering Named-digit-timeout waiting 0 seconds for more digits

11:42:02.450 SA.5558542245 Ca:0 DigitGathering State change >> DigitGathering->DigitGathering (CAS_Active)

11:42:02.451 SA.5558542245 Ca:0 DigitGathering sent: AcctPhoneMgr_cachg(CAS_Active) to PM

11:42:02.452 PM.0:2 State change >> SendingDigits->Call Pending

11:42:02.454 SA.5558542245 Ca:0 DigitGathering sent: call to SB

11:42:02.454 SA.5558542245 Ca:0 DigitGathering State change >> DigitGathering->CallPending (CAS_Active)

11:42:02.455 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: stopping

11:42:02.456 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: TDM unmap

11:42:02.456 RTP.CHANNEL fxs 0/2 - dsp 0/1.1 - Tone Detection: releasing RTP resource

11:42:02.457 TONESERVICES.EVENTS fxs 0/2 - dsp 0/1.1 - Tone Detection: release

11:42:02.458 SA.5558542245 rcvd: AcctPhoneMgr_billingCode from PM

11:42:02.459 SB.CALL 11025 Idle Called the call routine with 5553962120

11:42:02 SB.TGMgr For dialed number 5553962120, against template NXX-NXX-XXXX, on TrunkGroup SIP, the score is 1000

11:42:02.460 SB.CCM isMappable:

11:42:02.461 SB.CCM : Call Struct 0x2587810 : Call-ID = 11025

11:42:02.461 SB.CCM : Org Acct = 5558542245 Dst Acct = T02

11:42:02.462 SB.CCM : Org Port ID = 0/2.0 Dst Port ID = 0/0.0

11:42:02.462 SB.CCM : Org TID = Fxs Dst TID =

11:42:02.463 SB.CCM isMappable: Call Connection Type is TDM_TO_RTP

11:42:02.464 SB.CCM isMappable: Reserving RTP Channel 0/1.1

11:42:02.465 SB.CCM isMappable: Creating SDP Offer

11:42:02.468 SB.CCM updateOfferWithEndpointConfig: DTMF(NTE 101), VAD(off), ptime(5)

11:42:02.470 SB.CCM translateOffer: offer codec list: PCMU

11:42:02.470 SB.CCM translateOffer: revised offer codec list: PCMU

11:42:02.472 SB.CCM translateOffer: codec list after answerer: PCMU

11:42:02.475 SB.CCM translateOffer: DTMF signaling: answerer has no restrictions configured, passing offer(NTE 101) through

11:42:02.476 SB.CCM translateOffer: success

11:42:02 MEDIA.ANCHORING MANAGER Allocating media port.

11:42:02 MEDIA.ANCHORING ANCHORING getSubstitutePort: No matching callIdMap entry found for call 11025

11:42:02 MEDIA.ANCHORING ANCHORING Call ID map : Added new entry : call ID 11025 : session -1377186122INIP4127.0.0.3 : version 1 : index 2442

11:42:02 MEDIA.ANCHORING ANCHORING New media entry : type(5), callID(11025), sessionID(-1377186122INIP4127.0.0.3), original IP(127.0.0.3) ports(12442-12443), substitute IP(0.0.0.0) ports(12442-12443), RtpChannel(0/1.1), connection(0x2534d10), sdpOverride(5), me(0x3426310). RtpChannel 0/1.1

11:42:02.481 SB.CALL 11025 Idle Call sent from 5558542245 to T02 (5553962120)

jayh · ‎08-26-2013

Something really strange is going on. The phone is sending 706-396-2120 but the digits are being processed as 555-396-2120 internally. Do you also have a voice user with the exact pattern of either 706-396-2120 or 555-396-2120 ?

Post the complete configuration sans passwords, please.

Anonymous · ‎08-26-2013

Jayh,

No I missed changing that 706 to 555 when I was trying to scrub the configuration. Since I messed that up anyways heres the actual log for the call:

11:41:57.954 PM.0:2 Idle Processed OFFHOOK

11:41:57.955 PM.0:2 State change >> Idle->Requesting Dialtone

11:41:57.956 SA.7068542245 Ca:0 Idle rcvd: AcctPhoneMgr_appearance(ON) from PM

11:41:57.956 SA.7068542245 Ca:0 Idle State change >> Idle->DigitGathering (CAS_ReqDigits)

11:41:57.957 SA.7068542245 Ca:0 DigitGathering sent: AcctPhoneMgr_cachg(CAS_ReqDigits) to PM