PRI table Digit translation tables lose inbound Caller ID

[bassbill]

Here's one that I can't believe. If you have a number that's ported across your PRI, and you use the inbound tables to redirect the number, you lose any Caller ID to the old number - E.G.
Ported number: 555-6434
Ported to DID: 999-5200
Digits sent: 3 (434)
Inbound Table: Pattern(434)Expect(3)Del(3)Add(200)

Calls to 999-5200 GET Caller ID
Calls to 555-6434 DO NOT GET Caller ID
I've had the provider monitor the call, and all is well. As soon as he translated 434 to 200, sending me the DID only, Caller ID worked. This is an older Legend (R6.0, but I've had issues with newer switches as well. Anyone have any thoughts - I think I'm just stuck with this flaw.

 

[SYQUEST]

I am trying to understand your post. First of all the Legend/Magix switches do not port anything! That function is done at the carrier or service provider level with SS7 and the N1 database for LNP (Local Number Portability).

The example you show is NPA-555-6434 being changed to NPA-999-5200. Who is doing the changing? You show Inbound digit manipulation and you mention a provider doing translations too.

I assume the Legend is receiving a three digit feed. Then if 555-6434 is called you get 434 and for 999-5200 you get 200. Is that what happens? What kind of set is receiving the calls? Are the station numbers 434 and 200 assigned to separate phones?

What did the provider's monitor show when both numbers were called for the CID info? (Any digits received on a PRI are considered DID numbers!)

What kind of CO switch is connected to the PRI service?

....JIM....

 

[bassbill]

The number is being ported by the PRI provider. I should have said "directed to" 999-5200 instead. The telco sends 434 - my tables translate it to 200. After that is where is Caller ID fails. The CO switch is a 5E (AT&T)set to custom. The provider sees the ID sent the same on either inbound call

 

[SYQUEST]

What happens if you assign the 434 to an MLX display phone set and call the DID?

Are you using MLX display phones?

Does the CID work then?

Do you have both numbers, 555-6434 and 999-5200 in your DID block?

....JIM....

 

[bassbill]

If numbered 434 works fine (on MLX phones)
Blocks are for analog lines the provider sends 3 digits - my "0" table is as
Service: Any
Pattern:
Expected Digits: 3
Del:
Add:

 

[SYQUEST]

Hi Bassbill,

Well... MLX phones are the only display phones that work with CID on the Legend.

There is NO CID on analogue stations on the Legend/Magix.

I reread your original post, and some of the questions you answered, and I am still confused about what is not working or what you are trying to do.

Do you need both numbers to appear on one instrument?

....JIM....

 

[dagwoodsystems]

I know a way to pass Caller ID to analog stations.

Unfortunately, I'm also unsure as to whether that's what you're interested in or not.

 

[phonesrus]

Sy,
What I think BassBill is saying is that IF he uses inbound switch digit manipulation on the Merlin/Magix (434 to 200) then the M/M is dropping the inbound CLID, but if the carrier outpulses 200 instead of 434 for the "555-6434" the CLID is presented properly. I have seen this happen a couple of times on a 5E and we had to force the carrier to change the outpulse, but I think the issue is on the M/M in the drop/insert tables.

 

[bassbill]

Thank you phonesrus! Finally someone who understands! I had one of the top switch techs at the CO go through everything, and unless there was a fix in the software on a later release of Legend/Magix, I have a feeling I'm stuck with this problem, but I'm not done yet !!

 

[merlinman]

In looking through the POCKET REFERENCES, I saw nothing mentioned about an enhancement in later Releases.

 

[SYQUEST]

I COULD UNDERSTAND BETTER IF YOU WOULD HAVE ANSWERED THE QUESTIONS I POSTED!

....JIM....

 

[phonesrus]

MM, If I remember correctly the ones I had issues with were CEK4's that were upgraded to R-7 V10 via a flashcard. As a matter of course, I force carriers to change the outpuse for BTN's, if different from the DID range, on upgrade/conversions to save switch resources and make things less complicated to figure out in the future.
I don't know if it is a "bug" or maybe a flaw in the upgrade card, but it appears that in the process of the DNIS conversion in the Merlin R-7 the CLID is no longer passed to the receiving extension.
BB stated his was on R6.0
?????

 

[merlinman]

Phonesrus, that is interesting.

I am just trying to think if I have any CKE4's (R7) doing PRI.

I think all my PRI's are Magix, CKE5's.

I wonder if an upgrade to a CKE5 would help you bassbill.

At this point, I could only recommend such a thing as a test.

 

[bassbill]

I am also in the process of doing a test with a recent customer who has a Magix with a PRI & DIDs. I'm going to take one ext & renumber it, then digit manip that old ext's DID to the renumbered ext. - we'll see.
I also called our distributor's tech support (God forbid you call Avaya directly)and they have assured me that the inbound rounting has nothing to do with the Caller ID, and here's the real kicker - when the (434) number is called and translated it rings ext 200 with "Cover DID?#" - which we all know means an invalid destination, and that is the reason the Caller ID is not passed - so says tech support. OK - Now I've got one for him - If it IS an invalid destination HOW was it properly routed via the inbound tables??? The plot thickens! Thanks for all your input guys - I'm still not ready to let this one go. My switch tech guru is willing to conference with tech support and escalate this to resolve it one way or the other - hopefully I'll have an offical answer by the weekend.

 

[merlinman]

FYI, I was a Tier-3 Lucent/Avaya Tech Support engineer on this product, since before it was a product.

I would wonder why you are getting "Cover DID #?" if all things are programmed correctly. (Number of digits sent and stuff like that)

 

[bassbill]

That is baffling to me as well and the only real way to test is to point the main number at a different extension (DID)and if it still returns to the console, then we may be onto something. Another thing I considered is renumbering the LDN since it is a Queued console and see if that helps.

 

[tdaugirdas]

To: DagwoodSystems - I have a bunch of people interested in the way you have found to pass Caller ID to an analog station. There is a seperate post on the topic. Please respond...Thanks...Tom

Tom Daugirdas,
President
STCG, Inc.
stcg.com

 

[merlinman]

I HATE QCC's PERIOD!

There is usually NO NEED TO HAVE ONE, and they only cause problems.

 

[bassbill]

How DO you pass Caller ID to those pesky analog stations?

 

[bassbill]

OK Folks - this HAS to be software related because:
I used a customer of mine who has a PRI with the same provider and setup. I renumbered a DID ext, then setup a table to convert the inbound DID to the renumbered station, which passed Caller ID both times - this was an R3 Magix, but still the test proved the ID is sent. The provider's tech also sent me 2 PM's from both the trouble switch and the one that works correctly to show that there was nothing different in the circuits regarding the ID issue.