How to send different PUBNUM depending on the trunk

[G.Fiszt]

Hi everyone.

I have to configure the following in the HiPath 4000:
I got one ISDN trunk(DIUN2) that is used to place calls between the 4K and a NEC PBX and a SIP trunk(STMI4) that is used to place calls between the 4K and an Asterisk PBX. The calls are working just fine, the issue is that when I call to the extensions in the NEC PBX, it is supposed to send a generic caller ID (6500) and when I call to the extensions in the Asterisk PBX, it is supposed to send the actual caller ID (65xx).

The PUBNUM is set to send 6500 and both systems (NEC and Asterisk) are receiving this identification.

The question is: Considering that both trunks send the number that is configured in the PUBNUM field, is there a way to configure the caller ID to be different for each trunk?

Thanks!

 

[donb01]

I'm not an expert on the subject of trunking, but I'm going to say No.

I have an ISDN PRI environment, and I have 3 choices: Put in the full 10-digit actual number, put in any full 10-digit number PROVISIONED ON THAT PRI, or put in an "invalid" pubnum (less than 10 digits, or a number that is NOT provisioned on that PRI. The outcome of the 3 is that the PRI will send out the actual 10-digit number if it is provisioned on the PRI it is going out of, the "spoofed" number as long as it is on the PRI it is going out of, or the "toll guide" number that is defined on the PRI as default. (I don't know how the spammers spoof numbers because I can change my numbers to anything I wasnt as long as I own the number and it is on THAT PRI, but I would never be able to send out someone else's number)...

In addition to that the station has the ability to display the station information to both "inside" and "outside" calls, display the extension to "inside" calls but an 'alternate' number to "outside" calls, or do not display station number to either - in which case outside calls will give "unknown" for the caller ID (and people with privacy manager will reject the calls), and internal callers will also be notified the number is restricted or blocked. This is achieved using the "way to display" setting in Assistant or the "SSTNO" parameter in SBCSU.

There is no way to specify multiple PUBNUM for a station that I am aware of.

However, if you mess around with your general digit translation rules (GDTR) table you might be able to say if a call comes in as 65xx change the number to 85xx or something similar. There are probably other ways to skin that cat, but all of them will involve digit manipulation of some kind - either when you dial out or when you receive the call.

Don Bruechert, Voice Comm Analyst II
CareTech Solutions @ Holy Family Memorial
Manitowoc, WI, USA

 

[G.Fiszt]

Thanks for your reply Don!

I am also thinking that is not possible, I just want to be sure.

About the spammers, you said that you don't know how they change the identification, it depends whether the provider allows it or not. For example, here in Brazil, there are some providers that do not analyze the numbers you are sending and it is very common to receive some calls (mostly from call centers) where the identification is something like: 88888888 or even 00000, pretty weird indeed.

 

[Moriendi]

You don't really want to send different PUBNUM, you want the real number on one trunk, and PUBNUM on the other.

You don't mention the protocol to NEC.

If you set a PUBNUM in SDAT, and the protocol is ECMAV2 (as will be used also for the SIP STMI), then the outgoing setup gains an ISOAddCallingPartyNum element, so both the real number is transmitted in the normal calling party number, and the PUBNUM is sent in the new additional element. Far end may or may not make use of that additional element, how will it decide what to use? Probably it will ignore it. If in the outgoing LDAT you set LATTR PUBNUM, then that additional element disappears, and the PUBNUM appears in the calling party number.

So if you have a PUBNUM of 6500, then you just need to make sure that LDAT LATTR has PUBNUM in it to the NEC, and the LDAT to Asterix does not, I doubt that additional number element will be tranmitted to native SIP, I'd expect it to be discarded. SIP trace would show.

ETSI protocol works a little different, it won't generate the additional calling party number element, and LATTR PUBNUM is required for it to do anything. Also NPI should be ISDN in this case. Probabkly you are not using ETSI anyway.

You can also edit with KNMAT and REPEXT which uses the SBCSU SSTNO parameter Don mentions, but you might find that has knock on effects elsewhere over other trunks, I'd try pubnum/lattr first. Check the LDATs.

 

[G.Fiszt]

Thanks Moriendi.

You guessed correctly, indeed what I have to do is to send the real number on one trunk and PUBNUM on the other.
I did what you have suggested, removing the PUBNUM parameter from the LDAT that was supposed to send the real number and it worked just fine.
Thank you all for helping me.

 

[eniyamath]

cha-sdat