mountain!!

You have a couple of ways to do this:

1. Don't send a CPN in the SETUP message to the central office. This forces the central office to send your BTN as the CLID.

2. If you want a CLID other than your billing number sent, then you will have to send it in your SETUP message to the central office and they will pass it on.

JohnnyGrep

It is not the number that I want to force, but the calling name.

EricP

Here is how you do it on a Regular T1.

TABLE: CXGRP
>pos 682
682
Y 7144829100
N
N
N
N
N
N
( RMR ) ( RMT )$
>cha
SPB: Y
>
BILLNO:
>
CTD: N
>
FCTDNTER: N
>
FCTDNTRA: N
>
FCTDINT: N
>
EWATS: N
>
EWATSI: N
>
PXOPTION: RMR
>
PXOPTION: RMT

PXOPTION:
>cnum
CLGNUM:
>
BLKPRES: N
>
PXOPTION:
>cnam
CLGNAME:
>Century_21

Here is how you do it on a PRI

Adding caller id to a pri
Ni2 allows the cust to outpulse ext #’s, dms 100 will always use the btn. Table ltdata is the protocol has ni2 can override what the customer sends us. But there must be these following touples. For outbound caller id outbound the ltdata needs to be serv always always with the btn updated in lidb for the customer name.


Table Ltdata
>pos pra 929 serv
PRA 929 SERV
SERV Y N SCREENED ALWAYS (BNS SBN) $
>up
PRA 929 DN
DN 503 111 1111 $ THIS MUST BE HERE TO OVERIDE THE CUSTOMER

IF THAT DOES NOT WORK ADD THIS
>add pra 929 cli cli $

>pos ISDN1 203 SERV
ISDN1 203 SERV
SERV Y Y SCREENED ALWAYS (BNS SBN) $
>cha
DATATYPE: SERV
>
AUDTRMT: Y
>n
CGNREQD: Y
>
CGNDELV: SCREENED
>always
CDNDELV: ALWAYS
>
OPTION: BNS
>
BNS: SBN
>
OPTION:
>tcap_cnam
CNAM_SUSP:
>n
OPTION:
>$
TUPLE TO BE CHANGED:
ISDN1 203 SERV
SERV N Y ALWAYS ALWAYS (BNS SBN) (TCAP_CNAM N) $
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT.
>y
TUPLE CHANGED
WRITTEN TO JOURNAL FILE AS JF NUMBER 966

EricP

Forgot to add in my post that on PRI's you will need to add the # into LIDB or whatever name lookup database that you have, PRI's will only send out the #.

mountain!!

You can not force a calling name. If you send a calling name to a central office, they throw that information element away and do not pass it on. As state above by EricP, you must update the public name database (LIDB). This is done through your local LEC and may cost you ectra if each extenion will have a different name.

Calling name delivery is not an originating feature, but rather a terminating feature. Thus the terminating central office looks up the name in the database and sends it to the called number. This is why you need to update that database with names for each calling number.

In the public network, even if a name is in the SS7 message sent across the network, LECs do not extract or use that name. In a private network, the name can be used.

mountain!!

I'll step back a couple of steps. Where the originator and terminator are both PRI, you can pass a calling name, but not in the usual manner. You need to send a special CODESET (I think it is CODESET 5 on Nortel equipment and CODESET 6 on Avaya/Lucent). This codeset (which can contain a name) is sent across the network and can be sent to the terminator as a special codeset. However, the terminating PBX must be setup to accept and translate this CODESET. Also, if you are interfacing with a DMS central office, you need to ask them to map the CODESET to the ATP element of the SS7 message.

If you want to venture this far, let me know and I can give the central office datafill.

EricP

The clips that I pasted in my notes were from a DMS500. They can pass caller id, in-fact I have a note in there that says how to block it. As long as the carrier will allow them to pass caller-id it will work. The only issue comes into play when going to a different carrier if they ignore the caller ID and do a dip on the originating number it may show blank if LIDB or the name data-base being used is not updated. This is from a carrier point of view.

mountain!!

They can pass calling number.....not calling name. In the PUBLIC network, the terminating end will always do a dip to the LIDB database. It will not use the calling name in the SS7 message (although I have never seen a caliing name in the Calling Name IE in an SS7 message - it is always in the ATP IE via a CODESET). I do know if the DMS receives a name over a PRI, it will not populate that name into the SS7 message unless specifically mapped via table ISDNPARM. It just throws the name away.