Feature Request: Delay in caller ID

[shuotari2]

We have noticed that when the system begins ringing, we do not get caller ID shown on the displays until the second ring.  One of my engineers said that on other systems you can set them to delay ringing until the second ring until caller ID is available.

It would be nice if the uc320w would allow us to delay incomming call notification until the caller ID information is available.  At this point, our staff is waiting until the second ring, waiting to see who is calling in.

Scott Huotari

Creative Computer Solutions, Inc.

[blaw]

Hi Scott,

First of all, it is a FXO only issue. It has to do with callerID not immediately presented to the UC320 at the first ring. The only alternative is to hide this fact via delayed ringing.

Guess what, it is how the phone behave (delayed ringing) when we started our market trial. Then we got feedback from the majority of the customers that they want it to ring immediately. This is to avoid the preception from their own customers they are slow in answering phone calls. The few seconds add up if they happen to be slightly busy in getting to the phone. And that can lead to abandoned calls with impatient callers. Even there is no abandoned call, not good for the business image when every client call is now answered 5 seconds or so later than they used to be. Besides for most business, they will pick up the phone no matter who call. Maybe you can tell us more about this client's application.

We will consider the feature request. But just to let you know it is already behaving the desired way base on customer feedback from market trial. One possibility is to make this behavior programmable. But then it complicates the system with one more parameter to program.

Regards,

Bassanio

[David Trad]

Hi Scott,

I would also like to point that which appears it might not have been mentioned, that in some countries the CID is not always presented imediatly as well, sometimes it can take up to two rings before it is presented to the CPE, this can in fact be shown on the UC-500 series when debugging the VPM signal when it is on a PSTN/Analogue trunk line, this is not so much an issue with ISDN/PRI services as the CID is usually passed on at the same time (PRI it is passed with the signaling channel).

I hope this also helps with clearing up the information as well.

Cheers,

David.

[Andrey Cassemiro]

Good point David,

Only to complement your answer, below are the Methods supported on our equipements just as an example that in some CID it does not send in the first Ring.

The following choices are available:
•Bellcore (N.Amer,China)—CID, CIDCW, and VMWI. FSK sent after first ring (same as ETSI FSK sent after first ring) (no polarity reversal or DTAS).
•DTMF (Finland, Sweden)—CID only. DTMF sent after polarity reversal (and no DTAS) and before first ring.
•DTMF (Denmark)—CID only. DTMF sent after polarity reversal (and no DTAS) and before first ring.
•ETSI DTMF—CID only. DTMF sent after DTAS (and no polarity reversal) and before first ring.
•ETSI DTMF With PR—CID only. DTMF sent after polarity reversal and DTAS and before first ring.
•ETSI DTMF After Ring—CID only. DTMF sent after first ring (no polarity reversal or DTAS).
•ETSI FSK—CID, CIDCW, and VMWI. FSK sent after DTAS (but no polarity reversal) and before first ring. Waits for ACK from CPE after DTAS for CIDCW.
•ETSI FSK With PR (UK)—CID, CIDCW, and VMWI. FSK is sent after polarity reversal and DTAS and before first ring. Waits for ACK from CPE after DTAS for CIDCW. Polarity reversal is applied only if equipment is on hook.

Thanks,

Regards.

Andrey Cassemiro.