Incoming Call Handling Treatment 1

[rtsoi]

Hi,

We installed a new PRI and Trunk Group and new set of DIDs (range 3500-3599)

When programming how the calls are routed, using "change inc tru", here are my parameters:

Called Length Called Number Del Insert
10 xxxxxx3500 10 yyyy
10 xxxxxx3501 10 zzzz

If I dial xxxxxx3500, it keeps ringing my Attendant consoles.

If I dial xxxxxx3501, it routes correctly to whatever extension I designate.

Any idea why only 3500 isn't working but every other DID I tried does?

Thanks

 

[kyle555]

If you switch yyyy and zzzz in your example, does the problem follow 3500/3501, or does it follow yyyy/zzzz?

Maybe when 3500 is being dialed, telco isn't actually sending all 10 digits, or sending something different that doesn't match your 3500 rule and that's why you're winding up at reception?

 

[rtsoi]

Whatever I insert for 3500, just goes to Attendant.

Whatever I insert for 3501-3599, routes correctly.

Every DID from 3501-3599 routes correctly to whatever extn I designate.

Only 3500 seems to be go to Attendant no matter what.

 

[ZeroZeroOne]

I suggest running a list trace tac [tac#] for the new trunk and watching what happens when you call 3500.

Any entries for Calltype Analysis? How about AAR, if 3500 was used at some point and the programming remains?

 

[rtsoi]

I did the "list trace tac" and it was routing my call to extn 3500, which doesn't exist so it explains why its defaulting to the operator.

Can you tell me where to check if any old programming is overriding my current settings?

Thanks

 

[mojoputter]

Display Listed-Directory-Numbers, what do you have in that field..?

 

[rtsoi]

Only 5000 which is the attendant.

 

[ZeroZeroOne]

Can you post any of your findings, such as the list trace? That should give you a hint if AAR is getting involved. Also, please verify the software version of your PBX.

In general,
display calltype analysis
or list aar analysis and look through the whole list.
You may need to run display aar analysis location all and display aar analysis location [loc #] for for your specific locations, if necessary.
display aar digit-conversion location all and for each location.

I would also double check your incoming call handling form again to make sure your rules are correct. One fat-fingered digit will throw everything off. If you have a more generic rule, perhaps that is what is working:

change inc-call-handling-trmt trunk-group1                 Page 1 of X
                        INCOMING CALL HANDLING TREATMENT

     Service/   Called     Called         Del      Insert
     Feature     Len       Number
   other________  10    5557781234_____   10_   4321__________
   other________  10_   555777_________   6__   ______________
   _____________  ___   _______________   ___   ______________

In this example, normal DIDs are converted to 4-digit extensions that match the last 4-digits. I want one DID (555 777 1234) to go to a specific extension (4321) but since the number is wrong (555 778 1234) then it won't work at all.

These are only guesses but I hope they point you in the right direction.

 

[rtsoi]

Here is the TAC trace

Here is my setting for this trunk group. I verified there are no typos. DID 3582 routes correctly to x5025 but DID 3500 doesn't.

I ran the other commands you suggested but didn't find 3500 anywhere.

Thanks for your help.

 

[mojoputter]

How about list usage ext 3500..? maybe you've done that one already

 

[rtsoi]

Already tried that.

No data to list.

 

[ZeroZeroOne]

Hmmm... Based on the trace and how incoming call handling is behaving (or not), there aren't too many things that would process a call before call handling... how about on the trunk group form? Anything such as a night service destination (page 1)?

How about page 2:
What is the Digit Handling (in/out)? Will be some combination of enbloc and/or overlap
If overlap is used for "in" then additional fields are available, such as Digit treatment and Digits.
(Overlap would require entries in ARS digit conversion and I'm pretty sure incoming call handling wouldn't work at all so that's probably not it.)

Anything in the Incoming Calling number fields for delete or insert?

 

[rtsoi]

No Night Service, digit handling is enbloc/enbloc, and Incoming Calling Number for Delete and Insert are both blank.

 

[mojoputter]

Whats being displayed on the console when the call comes in, I assume the caller ID..?

 

[ZeroZeroOne]

Calls to "3500" are probably ringing to the attendant due to vacant number routing. The Uniform Dial Plan should have an entry matching the extension range and length, then deleting digits and inserting the attendant extension.

display uniform-dialplan 9                                      Page   1 of   2
                       UNIFORM DIAL PLAN TABLE
                                                              Percent Full: 0

  Matching                   Insert              Node
  Pattern       Len Del      Digits     Net Conv Num
 9               5   5       61111      ext  n

All 5-digit dial strings beginning with 9 will route to extension 61111.

This works best when the dialplan-parameters extension search order is set for local-extensions-first. That way, dialing a 5-digit extension starting with 9 will work as you would expect and ring the station first. if no station existed then the UDP table is checked to see if there are any additional routing.

Sorry, I like to ramble...

Back to incoming call-handling.... would you try a 4-digit entry for "3500" and direct that to your test destination? About the only thing left to check is what the carrier is sending.

 

[rtsoi]

I changed the Incoming Call Handling Treatment to 4 digit Call Length, Dialed Number to 3500, Delete 4, and Insert 5025 and it worked...

However, I also changed my other test DID (3582) and that now doesn't work.

It seems 3500 only works when 4 digit/delete 4 and every other DID is 10 digit/delete 10.

 

[ZeroZeroOne]

Yay? We figured it out?

That seems random and worthy of a conversation with the carrier. I haven't dealt with too many carriers but I thought they only sent one format per PRI, not multiple. That's why I didn't think of that sooner.

Assumptions, assumptions....

 

[rtsoi]

Thank you for your help.

I will talk to the carrier.

 

[mojoputter]

Nice job ZeroZeroOne, star for you