The phone system takes care of all that. When you program the ksu for caller id it will automatically wait to let the cid information get through on each line you set for cid. The cid info also does come through on the smdr.
charles ----- Original Message ----- From: "Paul H. Gusciora" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, January 24, 2002 1:56 AM Subject: KX-T: CID with KX-TD 816 & TVS-75 > CID (Caller ID, also known as CPID Calling Party IDentification) on POTS CO > lines is sent as a burst of data on a Bell-303 modem carrier between the > first and second rings. > > If the CO line goes off-hook immediately after the first ring, the CID data > is never sent, therefore can never be received. > > If I understand your comments correctly, CID data is not received anywhere > -- not even the SMDR printer. If this is the case, perhaps before the > custom service was set up, the phone system delayed things enough so that > the CID data was sent (and received) before VM picked up. > > Options: > > 1. Delay answer on transfer to VM Custom Service for a few seconds > advantages: this will work as desired > disadvantages: It is not clear how to program the KX-TD1232 to do > this! > > As I understand it, one has to use DIL 1:1 to the VM extension group to > have the VM pick up incoming calls with no implied extension context (and > therefore get the Custom Service Menu instead of the extension mailbox). > DIL 1:N allows for a delay to a physical port, but DIL 1:1 to an extension > or extension group is immediate. Usually one sets the FWD B/NA timer to 3-5 > rings or so -- this is too long if everyone is expecting the VM to pick up. > Perhaps one can use a phantom extension, or an unused physical extension in > some sort of UCD overflow group to delay transfer from selected CO lines to > the VM ports? > > 2. Delay VM answer on all VM ports > advantages: this will work > disadvantages: VM always delays answering -- even for internal > calls and transfers. One could configure no delay during the day, and a > small delay at night, but that would be inconvienent for busineses with > irregular hours, as the VM night setting is on a fixed schedule and does > not track the phone system night setting. > > 3. Install ISDN-BRI or ISDN-PRI (T1) which transmits CPID as part of > the D channel call setup > advantages: generates revenue for the LEC, installer, and > Panasonic. > disadvantages: more complicated & expensive. > > Note that local tariffs might make ISDN-BRI attractive for other reasons. > Here in CA (Pacific Bell / Southwest Bell), a business POTS line costs > about 15 $/month, CPID costs 7.50 $/month (ouch!), but ISDN-BRI (2 B + 1 D > channels) costs 36 $/month. I think that one receives CPID and CNID (Called > Number IDentification) data for two lines in the ISDN-BRI rate. > > Paul H. Gusciora > San Rafael, CA > > ==== > Reply-To: <[EMAIL PROTECTED]> > From: "Bill Smith" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Importance: Normal > Subject: KX-T: CID with KX-TD 816 & TVS-75 > Sender: [EMAIL PROTECTED] > Date: Wed, 23 Jan 2002 17:26:34 -0500 > > I have a customer that claims until I set their TVS-75 up for custom > service, that they always could see the CID information in their 74XX > display phones before they would answer a call. I suspect that the way I > have the TVS set up it is transferring the calls to the extensions in a > supervised mode, therefore not permitting the CID info from getting to the > extension. If that is the cause, how can I change it so the CID will pass > prior to the call being answered and still keep the custom service menus > that I have set up for them? > > > > > _________________________________________________________________ > KX-T Mailing list --- http://kxthelp.com/ > Subscription changes: http://kxthelp.com/mailman/listinfo/kxt _________________________________________________________________ KX-T Mailing list --- http://kxthelp.com/ Subscription changes: http://kxthelp.com/mailman/listinfo/kxt
