8300: Incoming Fax numbers being re-routed to main line... 1

[pichels]

Hi-

We have a number of fax lines setup in our system on a 717AP card now.
They were ported from a POTS lines(dedicated).

A phone vendor helped us setup a "inc-call-handling-trmt trunk-group" entries and we've left the config alone.
Now, all of sudden - a few of our Fax lines are being re-routed to our softconsole or main line(receptionist).

We tried looking in the config for an entry for the fax line but cannot find it in the call handling?
And have been told to check if the DNIS is defined or default route has been changed?

Not sure where to start or what to look for with little experience.
Please let me know if you need further details.
Thanks for any help.

-P

 

[Stinney]

Sounds like your recent change to the inc-call-handling-trmt trunk-group is directing these fax numbers to an extension in your system that is not programmed and so they are following the DID/Tie/ISDN/SIP Intercept Treatment on page 1 of the system parameters features setup.

The last 4 digits of the phone number are usually the incoming DNIS for the number. So you need to determine what the inc-call-handling-trmt trunk-group is doing to the extension and where it's trying to send it vs where it should be sending it.

Can you tell us what entry was made in the inc-call-handling-trmt trunk-group?

- Stinney

I love learning and passing on knowledge. "Because knowing is half the battle".... GI JOOOOOE!

 

[pichels]

Hi Stinney-

Appears that maybe the inc-call handling trunk group is set correctly - we had this config setup and working fine.

--> change inc-call-handling-trmt trunk-group 11 Page 1 of 3
INCOMING CALL HANDLING TREATMENT
Service/ Called Called Del Insert Per Call Night
Feature Len Number CPN/BN Serv
public-ntwrk 10 XXX2734554 10 7839

We think maybe one of our default "coverage paths" would be the result of the call being forwarded/routed to our main-line/receptionist(softconsole).

Appears these were POTS lines so they would not be setup.configured in our phone switch at all.
Perhaps the DNIS from the LEC(Telco) was being incorrectly routed - does that sound right?
Not sure since we did not change anything...
Thx for your help.

-P

 

[Stinney]

So in your incoming-call-handling xxx2734554 your sending it to extension 7839.

So if you execute the command: list trace station 7839

where does the trace show the call routing?

- Stinney
"Scire ubi aliquid invenire possis, ea demum maxima pars eruditionis est"

"To know where to find anything is, after all, the greatest part of education"

 

[pichels]

Hi Stinney-

Sorry about the late response - so far all is well around here.
Not sure if it was the LEC or if our changed by our vendor helped...not sure of the details - sorry!

However - thanks for the trace - I'll use that when a call is reported.
Though not sure if it can help unless it is run continuously until the next issue occurs.
Appears routing is fine for us internally - outgoing is ok - but, as mentioned, incoming is the issue.

And as you say - when calls come into 4554 and should be directed to 7839...if they are not sent to 4554 by the LEC - what else can we do - right?
If he digits are incorrect from outside or routing doesn't get to 4554 - the PBX can't handle it properly for those calls - it may redirect to default coverage path which is the main line/operator.
We have a new provider and a new PRI - we also had outside routing issues with this new install.

Anything else to add or details you'd like to see?
Hope the above made sense.
Thanks again for your assistance.

-P

 

[Stinney]

If the LEC is now sending these down a PRI instead of over copper POTs, they should be sending DNIS on the line. Most likely 4554 for your number. But you should contact them and confirm what DNIS they are sending for that 2734554 number.

Your incoming call handling treatment for trunk 11 should probably be:

public-ntwrk 4 4554 4 7839

- Stinney
"Scire ubi aliquid invenire possis, ea demum maxima pars eruditionis est"

"To know where to find anything is, after all, the greatest part of education"

 

[pichels]

Hi Stinney-

Ok - I'll have to find the DNIS -- not sure.

Here is the result of that incoming trunk info:

change inc-call-handling-trmt trunk-group 11 Page 1 of 3
INCOMING CALL HANDLING TREATMENT
Service/ Called Called Del Insert Per Call Night
Feature Len Number CPN/BN Serv
public-ntwrk 10 XXX2734554 10 7839

Looks diff than what you were expecting?
Thx.

-P

 

[Stinney]

Yes, looks different than what I would expect. Usually a LEC sends a DNIS of 4 digits, but it can be more if you work with the LEC to do so.

So on our PRI we have a DID range of XXX-XXX-8xxx. The LEC sends a DNIS of 8xxx for each of the DID's dialed. We convert these in our incoming call handling treatment in the trunk to add a 3 in front of the DNIS because our extensions internally are 38xxx.

In your case, you could assume that the LEC is sending a DNIS of 4554 for this number. So your incoming call handling treatment should be looking for these 4 digits and converting them to the extension number you want the call to route to.

You need to confirm what is being sent on your PRI for DNIS for this number.

- Stinney
"Scire ubi aliquid invenire possis, ea demum maxima pars eruditionis est"

"To know where to find anything is, after all, the greatest part of education"

 

[pichels]

Ok - we confirmed that the LEC is sending 4 digits for DNIS.

We have not had any further FAX calls that I know of to the main /.800 number.
Last time we had issues it was the LEC mis-routing those numbers(DID's) we had ported improperly.

I think all is well for now.

If it were to act up again - is there a way to trace our incoming calls to check for the source number?
Thx again for your help.

-P