Incoming Caller ID

[TIgerV]

I tried here before, but we never got this done:

My Hipath 4k is behind a Nortel CS1000; and the Nortel sends 7 digits caller ID to the Hipath. (ie 356-1234)

The Hipath 4K rejects the Caller ID because it's not 10 digits. All I see is "PrivateNumber" on the displays behind the hipath.

Any ideas how I can just make the hipath force whatever it receives to the positions? Anything you want to look at (span config, routing tables, etc) let me know. I really need this to work somehow.

TIger

 

[sbcsu]

You need to trace the calls if not already done so.
It is probable that the Nortel is sending the call with an NPI which is incorrect.

 

[TIgerV]

Here is a trace (deciphered by the assistant). This call was placed from 356-3177 (Nortel) to 356-3216 (Hipath)


stai
Static Data: |PEN 01-01-001-001 TRKID BOARD DIU2U_M DEV S1B TGRP 40 | TCCID DAKS TRTBL GDTR | DEDSVC NONE PROTOCOL QSIG_ISO_V2 |PEN 01-01-001-001 TRKID BOARD DIU2U_M DEV S1B TGRP 40 | TCCID DAKS TRTBL GDTR | DEDSVC NONE PROTOCOL QSIG_ISO_V2 |PEN 01-01-001-001 TRKID BOARD DIU2U_M DEV S1B TGRP 40 | TCCID DAKS TRTBL GDTR | DEDSVC NONE PROTOCOL QSIG_ISO_V2 |PEN 01-01-001-001 TRKID BOARD DIU2U_M DEV S1B TGRP 40 | TCCID DAKS TRTBL GDTR | DEDSVC NONE PROTOCOL QSIG_ISO_V2 |PEN 01-01-001-000 TRKID BOARD DIU2U_M DEV S1B TGRP 1 | TCCID TRTBL DIDCR | DEDSVC NONE PROTOCOL ITU_ATT4ESS |PEN 01-01-001-000 TRKID BOARD DIU2U_M DEV S1B TGRP 1 | TCCID TRTBL DIDCR | DEDSVC NONE PROTOCOL ITU_ATT4ESS |PEN 01-01-001-000 TRKID BOARD DIU2U_M DEV S1B TGRP 1 | TCCID TRTBL DIDCR | DEDSVC NONE PROTOCOL ITU_ATT4ESS |PEN 01-01-001-000 TRKID BOARD DIU2U_M DEV S1B TGRP 1 | TCCID TRTBL DIDCR | DEDSVC NONE PROTOCOL ITU_ATT4ESS |PEN 01-01-001-000 TRKID BOARD DIU2U_M DEV S1B TGRP 1 | TCCID TRTBL DIDCR | DEDSVC NONE PROTOCOL ITU_ATT4ESS |PEN 01-01-001-000 TRKID BOARD DIU2U_M DEV S1B TGRP 1 | TCCID TRTBL DIDCR | DEDSVC NONE PROTOCOL ITU_ATT4ESS |PEN 01-01-001-000 TRKID BOARD DIU2U_M DEV S1B TGRP 1 | TCCID TRTBL DIDCR | DEDSVC NONE PROTOCOL ITU_ATT4ESS |PEN 01-01-001-000 TRKID BOARD DIU2U_M DEV S1B TGRP 1 | TCCID TRTBL DIDCR | DEDSVC NONE PROTOCOL ITU_ATT4ESS |PEN 01-01-001-000 TRKID BOARD DIU2U_M DEV S1B TGRP 1 | TCCID TRTBL DIDCR | DEDSVC NONE PROTOCOL ITU_ATT4ESS |PEN 01-01-001-000 TRKID BOARD DIU2U_M DEV S1B TGRP 1 | TCCID TRTBL DIDCR | DEDSVC NONE PROTOCOL ITU_ATT4ESS |PEN 01-01-001-000 TRKID BOARD DIU2U_M DEV S1B TGRP 1 | TCCID TRTBL DIDCR | DEDSVC NONE PROTOCOL ITU_ATT4ESS |PEN 01-01-001-000 TRKID BOARD DIU2U_M DEV S1B TGRP 1 | TCCID TRTBL DIDCR | DEDSVC NONE PROTOCOL ITU_ATT4ESS |
Direction Station/PEN BCH Call Reference Message Type Time<br>
Incoming 1-1-1-0 23 23 (H'17) SETUP (H'5) 17:54:12:770
ok 2289 "(Incoming SETUP (H'5) on 1-1-1-0)<br>
ProtocolDescriptor: Q.931 family (e.g. CorNet-N(Q), DSS1, ...) (H'8)<br>
CallReference:<br>
CallReferenceLength: 1<br>
CallReferenceFlag: 0<br>
CallReferenceValue: 23 (H'17)<br>
MessageType: SETUP (H'5)<br>
InfoElem: Bearer capability (H'4)<br>
HexData: 028090<br>
Length: 2 (H'2)<br>
CodingStandard: CCITT standardized coding (H'0)<br>
InformationTransferCapability: Speech (H'0)<br>
TransferMode: Circuit-mode / call independent signalling (H'0)<br>
InformationTransferRateAndMode: 64 kbit/s (H'10)<br>
InfoElem: Channel identification (H'18)<br>
HexData: 04E9808397<br>
Length: 4 (H'4)<br>
InterfaceIdentifierPresent: Interface explicitly identified in one or more octets beginning with octet 3.1<br>
InterfaceType: other than basic interface (e.g. primary rate)<br>
Preferred/Exclusive: exclusive; only indicated channel acceptable<br>
SignallingChannelIndicator: channel identified is not signalling channel (D-channel)<br>
InfoChannelSelection: as indicated in following octets<br>
InterfaceIdentifier: 0 (H'0)<br>
CodingStandard: CCITT standard<br>
Number/map: channel is indicated by number in following octet<br>
ChannelType: B-channel units (64 kbit/s)<br>
ChannelNumber: 23 (H'17)<br>
InfoElem: Calling party number (H'6C)<br>
HexData: 088933353633313737<br>
Length: 8 (H'8)<br>
NumberingPlanIdentification: Private numbering plan<br>
TypeOfNumber: Unknown (H'0)<br>
NumberDigits: "3563177"<br>
InfoElem: Called party number (H'70)<br>
HexData: 088933353633323136<br>
Length: 8 (H'8)<br>
NumberingPlanIdentification: Private numbering plan<br>
TypeOfNumber: Unknown (H'0)<br>
NumberDigits: "3563216"<br>
"<br>


--TIger

 

[sbcsu]

Can you tell the Nortel to NOT send the number as private numbering plan?

 

[TIgerV]

I will ask him. Thanks!

--TIger

 

[sbcsu]

Any news on this?
You do need LWNC (Line without node code) set in the COT of the trunk by the way.

 

[TIgerV]

My Nortel tech said he can't change the NPI; however we have a new PRI trunk that was established for Enhanced 911 services that is working smoothly, so I'm going to compare my routing and setup to theirs on the Nortel and see what we can change. If I can make the Caller ID, and local (on Nortel) dialing work, I'd be in heaven.

--TIger

 

[donb01]

Sorry to hijack your thread here, but I have a few questions about your E911 on PRI.

Are you processing E911 for more than one location in the same city/CO?

If yes, are you routing ALL of your E911 traffic from ALL sites through this one, or does each site send out its own E911??

If you are routing ALL E911 traffic thru this site, do you also receive ALL incoming DID calls for all sites on this PRI, or does each site have their own?

Who is your PRI/E911 Provider?


The reason I'm being nosey is because we bought a huge system upgrade and are planning to roll out E911. I have 7 sites in a hub and spoke configuration. Each site has its own independent PRI service, and it's own slate of DID numbers. Because our main (hub) site has 3 PRI circuits the plan was to fractionalize the center of the 3 PRI circuits and reserve 6 channels for E911 traffic. ALL E911 traffic from ALL sites would route to the hub, and from there the E911 system would provide the data to the PSAP. It all looks good on paper, but it seems the people at the vendor who engineered this dud not take into account there being some type of tarriff that says you are not allowed to send out E911 data from any PRI trunk if the DID number of the originator is not provisioned on that SAME PRI as the E911 call is going out on. I am investigating any possible ways to get around this, which is why if I can find out there is anybody that is doing just that without a problem, then I would like details of how they are doing it or provider contact information so I can tell them to stuff it - especially if the entity is located in Wisconsin. I am potentially looking at having to buy expensive, dedicated CAMA trunks for this purpose, but they can't even tell me right now if that will be acceptable either.

Thanks for anything you want to share, or anyone else who does. My provider is AT&T.

 

[TIgerV]

Sorry, but we are only processing E911 for our Campus area (about 200 acres).
It was purchased and engineered by a 3rd party.
I know I have heard in discussion about some of the items you mentioned, however.

Sorry, I can't help much more. I know our provider is INDigital, maybe they could help.



--TIger

 

[sbcsu]

On the CLI issue, ideally if you can borrow a PRI tester it would help to see what you are getting from the Meridian

 

[TIgerV]

I can check with the Nortel side, maybe they have a tester.
Supposedly, when Siemens was here, they tried all configurations on the NI2 protocol, and couldn't get the 2 switches to sync up, so we had to go to 4ESS (ESS4 on Nortel), and that's when we lost caller ID and the ability to dial numbers on the Nortel switch.
I want to change the protocol, but since I'm far from being a Hipath tech, there isn't much chance of that happening. However, the Contract stated that the switch must have Caller ID, so they may have to come out and help with it.
I am going to have a few on-site techs this week, I'll cover it with them.
Plus, seeing how the E911 folks (Cassidian and General Dynamics) set up their systems, I will understand more.

I wish there was a way to tell the Hipath "Take the number that the remote senda as calling number and display it as caller ID" That's all I need; since I really need the system to recognize calls in the queue and move some up. Caller ID is a convenience to some, but in my realm, it's just short of a requirement.

--TIger

 

[donb01]

Wouldn't you be able to monitor the D channel using the ISDN Trace utility on the 4K??

I've only used it a few times, but I could swear you can see the call set up and shut down information.

 

[TIgerV]

I showed you what Assistant shows. If I have to do it via AMO, I avoid it, because, frankly, I'm afraid of "expert mode". :-D

--TIger

 

[TIgerV]

I finally, after 6 months, got most of these problems fixed.

The NI-2 problem was an issue with the CO (Nortel CS100M) where they needed a patch. Once we brought the system up on NI2; I got callerID and ANI data both.

--TIger