btrain2871

I have an extension 8306 that is in my 'disp dialplan anal' as 8 4 digits = ext.

if I do a 'list uniform-dialplan 1' there is an entry in there for 8306 with 4 digits = ext.

This 8306 is the # of a hunt group which just routs to coverage and goes to a remote coverage path to an Int'l #.

the call keeps failing and when you do a traceroute it shows the call hit the huntgroup, then goes to the correct trunk group but in the dial sequence the digits are being manipulated and it's stripping the 011 and adding in 9191 at the end of the string causing the call to fail. Any ideas on this one?? That trunk group is used for just about all my int'l calls and if you dial the # directly it is fine. is this something in teh dialplan or the udp??

martinyoung

The first place I would look is the route pattern because that is where digits are usually stripped and added. How is your route pattern?

__________________
Marty
Retired Avaya DSIC tech

PBXtech.info

 

martinyoung

Has this call always failed or did that just start?

__________________
Marty
Retired Avaya DSIC tech

btrain2871

Pattern Number: 6 Pattern Name:
SCCAN? n Secure SIP? n
Grp FRL NPA Pfx Hop Toll No. Inserted DCS/ IXC
No Mrk Lmt List Del Digits QSIG
Dgts Intw
1: 8 3 212 1 3 n user
2: 6 3 212 1 3 n user
3: 9 3 212 1 n user
4: 11 3 212 1 n user
5: n user
6: n user
BCC VALUE TSC CA-TSC ITC BCIE Service/Feature PARM No. Numbering LAR
0 1 2 3 4 W Request Dgts Format
Subaddress
1: y y n n y n n bothept none
2: y n y y n n n bothept none
3: y n y y n n n rest none
4: y n y y y n n rest none
5: y y y y y n n rest none
6: y y y y y n n rest none

btrain2871

ouch.. that didn't look clear.

btrain2871

but when you dial the number directly w/o dialing the ext and going via coverage it rings through.

PBXtech.info

 

martinyoung

The other question I asked was, did this ever work?

__________________
Marty
Retired Avaya DSIC tech

btrain2871

yes.. not sure when it stopped though

btrain2871

martin, I attached a word doc that has 2 trace route results. 1st one from me dialing the intl' # directly and the 2nd dialing the internal ext that should route to that same number..

Attached Files

trace.doc (130.0 KB, 7 views)

martinyoung

When you dial the number directly you are not using the remote cover path. That raises two possibilities. Is the number programmed correctly in the cover remote table? And does that coverage path take you to the same route pattern that dialing it directly does?

What I see as possible right now is that you are being sent to a route pattern that strips the 011 off, however a route pattern does not insert digits at the end of the dial string so the 9191 is coming from somewhere else. Since you see this on the trace it is not happening in the CO, but in your switch.

Look at what I ask here and tell me if this ever worked.

__________________
Marty
Retired Avaya DSIC tech

martinyoung

I didn't get your attachments.

__________________
Marty
Retired Avaya DSIC tech

btrain2871

I see the attachment on the post. you sure you don't see it?

Anyhow.. i re-entered the remote coverage path number and had the same issue. So it's safe to assume that the trunk group is fine since I can dial it directly. the coverage path seems straight forward where point 1 is going to R40 which is the entry for this intl' #. Where would I find the stripping of digits..

btrain2871

does it matter that this ext. is a hunt group w/no members instead of a regular station?

btrain2871

Martin, I've changed the remote cov path # and put that in the cov path with the same result. I've made this coverage path active on my own ext and the same thing happened. I now just manually forwarded this extension to that intl' # and it works fine. I'd rather not have it forwarded and would like to use it via remote cov p. Where do you think I should look at this?

martinyoung

I see a difference in the way the call is handled in your document (yes, I have it now). For a test, please add a # at the end of the dial string in the remote table. Look at your two traces and you will see the successful call has that so lets try adding that to the call directly. A # terminates the dial string and no more digits can be added.

Another thing you might try is putting the number in its' entirety in ARS to make sure it routes the way you want.

__________________
Marty
Retired Avaya DSIC tech