Page 2 of 3

Posted: Wed Jan 07, 2015 11:29 am
by frankpc
Thank you Bill...

Found two errors so far:

I had Access through TAPI checked.
And did not have Enable Call Waiting id checked.

I will go through the tests again and try your alternate tests.

I forgot that you had mentioned that there was a Call Waiting ID option in the beta version.

Thanks again!

Success!

Posted: Thu Jan 08, 2015 9:53 am
by frankpc
Hi Bill,

Ascendis caller ID call waiting works perfectly!

I initiated a call from my cordless caller ID Call waiting home phone to a cell phone, and then calling my home from another cell phone results in the caller ID call waiting message to appear on the PC.

I also initiated a call from my cell phone to my home and answered that call with my cordless caller ID call waiting phone. Then calling home from another cell phone results in the caller ID call waiting mesaage to appear on the PC.

I don't think it makes a difference, but I have Netwaiting turned off. And I didn't make any changes to the setup other than those stated in my previous message.

I need to purchase another caller ID Call waiting phone to use here by the computer rather than to 'borrow' one from another room.

Interesting that it works so consistently. Why is there a difference between the standard caller ID protocol and the Call Waiting Caller ID protocol?

I want to make a few more tests without the caller ID call waiting phone involved. However, from what you have stated, I shouldn't expect caller ID call waiting to work.

Thank you for the support Bill.

Frank

Posted: Thu Jan 08, 2015 11:57 am
by Bill Root
Hi Frank,

I'm glad to hear it's working. The true test will be when you're actually talking on the phone -- this is when I expect false calls to appear. Please let me know what happens -- it's possible Ascendis Caller ID can do some filtering.
Why is there a difference between the standard caller ID protocol and the Call Waiting Caller ID protocol?
I don't have a good answer, but I'm not really qualified to give one. Certainly different things are happening on the phone line at the times caller ID and call waiting ID data is sent. In the first case the phone is ringing and a phone call connection is not present. The impedance is different at the two times.


Finest regards,
Bill Root
Ascendis Software LLC

Posted: Thu Jan 08, 2015 1:44 pm
by frankpc
I've only had one conversation so far and there was no false display. I will let you know how that goes.

I read an interesting article about call waiting caller ID. A signal is sent from the central office to your telephone when a second call comes in. It is up to your telephone to acknowlege that it is indeed capable of handling call waiting data. Upon receipt of the acknowledgement, the central office sends the caller ID data. So that is why a call waiting capable phone needs to be off hook. If data was sent to a phone that wasn't capable, the user would have to listen to the burst of FSK data.

However, with Netmeeting, no caller ID phone needs to be off hook and the acknowlegement is sent to the central office. And the CO, in turn sends the CID data to the PC. Of course, Netmeeting must be in use as the modem is transferring data for that to work.

Wouldn't it seem a utility similar to Netmeeting could respond appropriately to the CO's request such that the CO would respond with CID data during a voice rather than data conversation? It seems the difference is that the modem is off hook during the data transfer.

Of course, like you have stated, the potential market is just too small to support the programming required.

Thanks Bill,
Frank

Posted: Thu Jan 08, 2015 2:45 pm
by Bill Root
I read an interesting article about call waiting caller ID. A signal is sent from the central office to your telephone when a second call comes in. It is up to your telephone to acknowlege that it is indeed capable of handling call waiting data. Upon receipt of the acknowledgement, the central office sends the caller ID data.
So you were right all along. That seems logical, but I didn't think POTS would support something requiring the two-way communication.
So that is why a call waiting capable phone needs to be off hook. If data was sent to a phone that wasn't capable, the user would have to listen to the burst of FSK data.
And yet I've heard the data burst so many times (making it hard to follow the conversation) that I assumed it was always sent.
However, with Netmeeting, no caller ID phone needs to be off hook and the acknowlegement is sent to the central office. And the CO, in turn sends the CID data to the PC.
Do you know this for a fact? I was under the (possibly mistaken impression) that the ISP sent the data, escaped, in the data stream. It would seem tremendously difficult for a modem receiving data to process an inserted burst without confusing the two sets of data, and losing part of the main stream.
Wouldn't it seem a utility similar to Netmeeting could respond appropriately to the CO's request such that the CO would respond with CID data during a voice rather than data conversation? It seems the difference is that the modem is off hook during the data transfer.
I would imagine a program could put a modem off hook while a call is in progress, listen for the CO's CID pending signal, and respond appropriately. It would be tricky to do this without keeping the phone off the hook at all times, or interfering with hangups, redials, etc.


Finest regards,
Bill Root
Ascendis Software LLC

Posted: Thu Jan 08, 2015 4:13 pm
by frankpc
Bill Root wrote:
I read an interesting article about call waiting caller ID. A signal is sent from the central office to your telephone when a second call comes in. It is up to your telephone to acknowlege that it is indeed capable of handling call waiting data. Upon receipt of the acknowledgement, the central office sends the caller ID data.
So you were right all along. That seems logical, but I didn't think POTS would support something requiring the two-way communication.
Here is the link: https://www.google.com.vn/patents/US6785301
The farther you read the more detailed it gets. I didn't read far and I had to assume I understood as far as I read. You might come up with a different conclusion.
So that is why a call waiting capable phone needs to be off hook. If data was sent to a phone that wasn't capable, the user would have to listen to the burst of FSK data.
And yet I've heard the data burst so many times (making it hard to follow the conversation) that I assumed it was always sent.
I've heard that too. Until you tell me otherwise, I am going to assume the reason you hear it is because the switch in the telephone isn't fast enough to block it. Especially on a cordless phone.[/quote]
However, with Netmeeting, no caller ID phone needs to be off hook and the acknowlegement is sent to the central office. And the CO, in turn sends the CID data to the PC.
Do you know this for a fact? I was under the (possibly mistaken impression) that the ISP sent the data, escaped, in the data stream. It would seem tremendously difficult for a modem receiving data to process an inserted burst without confusing the two sets of data, and losing part of the main stream.
Your description makes sense. Unfortunately, my ISP does not have a way to connect with a modem. So I can't test it. But I'm just saying that the process seems to be that you connect to the distant data site via your CO to your ISP with your dial up modem and that Netmeeting advises you when you have a call come in during the connection. Then you have the choice of placing the data connection on hold while you take the voice call. So, a caller ID call waiting telephone was not involved with the setup of that. And it would seem that the second incoming call would have to be handled by the CO, so the plant at the CO would have to be the device that switches the calls to you. And the ISP would have to be able to deal with its line being placed on hold during the voice conversation (??)
Wouldn't it seem a utility similar to Netmeeting could respond appropriately to the CO's request such that the CO would respond with CID data during a voice rather than data conversation? It seems the difference is that the modem is off hook during the data transfer.
I would imagine a program could put a modem off hook while a call is in progress, listen for the CO's CID pending signal, and respond appropriately. It would be tricky to do this without keeping the phone off the hook at all times, or interfering with hangups, redials, etc.
True! Ascendis already monitors the modem for call waiting data without the modem being off hook. So when it detected that the CO was wanting to send call waiting data, could it just order the modem to go off hook and bridge the line long enough to send an acknowledgement to the CO? Seems it would be just like picking up a second telephone during a conversation already in progress. No risk of a disconnect in doing that.

Interesting stuff. I wish I knew something about it.

take care Bill,
Frank

Posted: Thu Jan 08, 2015 8:43 pm
by Bill Root
Here is the link: https://www.google.com.vn/patents/US6785301
The farther you read the more detailed it gets. I didn't read far and I had to assume I understood as far as I read. You might come up with a different conclusion.
That certainly seems to confirm your point. I'm convinced.
And yet I've heard the data burst so many times (making it hard to follow the conversation) that I assumed it was always sent.
I've heard that too. Until you tell me otherwise, I am going to assume the reason you hear it is because the switch in the telephone isn't fast enough to block it. Especially on a cordless phone.
From your referenced document (emphasis mine):
The central office uses Frequency Shift Keying (FSK) signals for sending the information about the second caller to the caller ID box. To prevent the user from hearing all of these FSK signals, the caller ID box temporarily breaks the downstream voice path between the central office switch and the user's telephone. The central office switch will not send the FSK signals unless the calling party ID box replies with an acknowledgement signal. This prevents FSK signals from reaching a telephone that does not have a caller ID box. After the FSK signals have been transmitted from the central office to the caller ID box, the voice path is reestablished.
This suggests that the user would hear the FSK signals (the call-waiting-ID data) if the user was on a telephone not connected in series with the caller ID box or phone. Thus, depending on the wiring, or whether a second listener was on a non-call-waiting-ID-phone, one might hear the tones. Also, if the user was on a properly wired phone, s/he might hear a break in the voice of the caller while the caller ID box blocked the audio.

Of course, your explanation is plausible too. I would also not be surprised if some (probably inexpensive) call-waiting-ID phones did not block the FSK audio, or not properly.
But I'm just saying that the process seems to be that you connect to the distant data site via your CO to your ISP with your dial up modem and that Netmeeting advises you when you have a call come in during the connection. Then you have the choice of placing the data connection on hold while you take the voice call. So, a caller ID call waiting telephone was not involved with the setup of that. And it would seem that the second incoming call would have to be handled by the CO, so the plant at the CO would have to be the device that switches the calls to you. And the ISP would have to be able to deal with its line being placed on hold during the voice conversation (??)
After reading http://modemsite.com/56k/v92moh.asp, I think my previous thoughts overestimated the technology. You make a valid point about the CO needing to switch the line. My current theory is that the definition of a "compatible" ISP is one with modems that support temporary loss of carrier without disconnecting. So, when the user's modem detects a call waiting call and the user decides to take it, the computer tells the modem to flash, putting the modem connection on hold. When the user completes the secondary call, the modems resume the connection.
Ascendis already monitors the modem for call waiting data without the modem being off hook.
Yes, but the modem is doing the hard part. Ascendis Caller ID is always listening to the modem.
So when it detected that the CO was wanting to send call waiting data, could it just order the modem to go off hook and bridge the line long enough to send an acknowledgement to the CO?
Right now Ascendis Caller ID only detects call waiting data when the properly configured Zoom 3095 modem provides it. Without that feature, Ascendis Caller ID would have to keep the modem off hook when it thought a call was in progress, which is probably impossible to determine in a general sense for all modems.
Seems it would be just like picking up a second telephone during a conversation already in progress. No risk of a disconnect in doing that.
The (first) trick is knowing when the conversation is in progress. I don't see how it would be worth the effort.


Finest regards,
Bill Root
Ascendis Software LLC

Posted: Fri Jan 09, 2015 10:25 am
by frankpc
Hi Bill,

I have no caller ID box. And all my caller ID phones are cordless. So that is why I figured the reason I hear the burst of data is because the phones do not mute fast enough to avoid the data. But, like you say, it is annoying.

I have a wired CID phone on order so it will be interesting to see how well that works.

I have a free Juno account just for the sake of testing the Netwaiting program. But when I connect to Juno, I am informed it is not v.92 compatible. And Modem On Hold does not work. So much for that test.

As you say, "the modem is doing the hard part" - but Ascendis is the only software I am aware of that is able to display the call waiting CID. That says a lot for your programmers.

I don't know the protocol involved and correct me where I am wrong here: It would seem you wouldn't need to know when a conversation was in progress. All Ascendis would do is monitor the modem's output. If it detected a 'RING', it would wait for the CID data. If it didn't detect a 'RING', but instead detected either CID data or it detected the inquiry from the Central Office asking whether a Call Waiting telephone or box was available, it would know CID data was about to come. Of course, maybe it wouldn't need to detect the 'RING' nor detect the CO inquiry to extract the CID data if and when it did show up.

I would like to see Ascendis respond to the CO inquiry by taking the modem off line long enough to send an appropriate acknowledgement signal. However, in this day and age, when you are in a telephone conversation, the odds are pretty good that you are using a CID/Call Waiting capable phone and the phone will handle the acknowledgement. So, like you say, "... not worth the programming effort..." Worse: If the CO received an acknowlegement from the modem and from the phone, a clash might occur and the CO would not be properly advised.

But still, it is interesting. And I would like to understand more about the protocol involved. Ascendis is nice and has all the bases covered.

Thank you Bill,

Frank

Posted: Fri Jan 09, 2015 11:00 am
by Bill Root
Hi Frank,
I don't know the protocol involved and correct me where I am wrong here: It would seem you wouldn't need to know when a conversation was in progress. All Ascendis would do is monitor the modem's output. If it detected a 'RING', it would wait for the CID data. If it didn't detect a 'RING', but instead detected either CID data or it detected the inquiry from the Central Office asking whether a Call Waiting telephone or box was available, it would know CID data was about to come. Of course, maybe it wouldn't need to detect the 'RING' nor detect the CO inquiry to extract the CID data if and when it did show up.
As far as I know, the modem doesn't indicate that the CO is asking whether a call waiting ID device is present. You can watch the Line Monitor log (on the Help menu under Diagnostics) to see what the modem says and when. For this reason I assumed the only way to tell would be to put the modem off hook and hope to discern some audio signal.
I would like to see Ascendis respond to the CO inquiry by taking the modem off line long enough to send an appropriate acknowledgement signal.
That patent you referenced indicated that packet-switched voice connections (aka VOIP) could not respond to the inquiry fast enough. Assuming that is correct, I doubt Ascendis Caller ID could detect the request and respond fast enough. Maybe a driver could if the computer wasn't too busy.

Nonetheless this is interesting material and I appreciate the information you provided!


Finest regards,
Bill Root
Ascendis Software LLC

Posted: Fri Jan 09, 2015 9:10 pm
by frankpc
Bill Root wrote:As far as I know, the modem doesn't indicate that the CO is asking whether a call waiting ID device is present. You can watch the Line Monitor log (on the Help menu under Diagnostics) to see what the modem says and when. For this reason I assumed the only way to tell would be to put the modem off hook and hope to discern some audio signal.
That patent you referenced indicated that packet-switched voice connections (aka VOIP) could not respond to the inquiry fast enough. Assuming that is correct, I doubt Ascendis Caller ID could detect the request and respond fast enough. Maybe a driver could if the computer wasn't too busy.
As I was sending that last posting, I realized you really can't have Ascendis acknowledge a message that would also be acknowledged by the CID telephone. The return messages would interfere with each other. Right? I suppose Ascendis could respond if you weren't also using a CID phone. But Ascendis wouldn't be able to know that.

So like you had already determined, just use a CID phone in parallel with Ascendis and all would be well. I need to read through the Line Monitor Log. I didn't know about that. That might teach me something.

Thanks Bill,
Frank

Posted: Sat Jan 10, 2015 9:35 am
by Bill Root
As I was sending that last posting, I realized you really can't have Ascendis acknowledge a message that would also be acknowledged by the CID telephone. The return messages would interfere with each other. Right?
That sounds logical to me.
I suppose Ascendis could respond if you weren't also using a CID phone. But Ascendis wouldn't be able to know that.
Were it possible for Ascendis Caller ID to respond to the call-waiting-ID prompt, it might include a configuration option. But if misconfigured, I expect it would cause the problem you supposed.


Finest regards,
Bill Root
Ascendis Software LLC

Posted: Sat Jan 10, 2015 9:58 am
by frankpc
I suppose Ascendis could respond if you weren't also using a CID phone. But Ascendis wouldn't be able to know that.
Were it possible for Ascendis Caller ID to respond to the call-waiting-ID prompt, it might include a configuration option. But if misconfigured, I expect it would cause the problem you supposed.
Great point! Ascendis seems to have every base covered and it would have the configuration option you mention. A further problem could be in cases like mine where some phones are CID and some aren't. You'd have to set the option to 'do not respond'. When the new CID phone arrives here, the phones we use most often will all be CID/Call Waiting phones.

I haven't had any false indications thus far by the way with the beta version and Call Waiting.

CU Bill,
Frank

Posted: Sat Jan 10, 2015 10:09 am
by Bill Root
When the new CID phone arrives here, the phones we use most often will all be CID/Call Waiting phones.
I do wonder what happens when two call-waiting-ID phones are off the hook when the call waiting ID signal arrives. Or a call-waiting-ID box and phone. Do they both respond, possibly causing the problem you supposed?
I haven't had any false indications thus far by the way with the beta version and Call Waiting.
That's great!


Finest regards,
Bill Root
Ascendis Software LLC

Posted: Sat Jan 10, 2015 10:58 am
by frankpc
I do wonder what happens when two call-waiting-ID phones are off the hook when the call waiting ID signal arrives. Or a call-waiting-ID box and phone. Do they both respond, possibly causing the problem you supposed?
I was wondering the same thing. Could it be that the inital CO query (to determine whether the phone is call waiting capable) comes in along with the CID data before any phone is taken off hook and then as soon as the first phone goes off hook, it immediately responds to or ignores the query?

It would seem that if that sort of handshaking was postponed until an actual second call did come in, that a non call waiting phone would pass that (initial query) audio burst through to your ear. Also, like you say, if more than one Call waiting capable phone was off hook, they would all respond.

I would like to find a nice short and sweet description of the entire process. There has got to be such a description available.

CU Bill,
Frank

Posted: Sun Jan 11, 2015 10:10 am
by Bill Root
I was wondering the same thing. Could it be that the inital CO query (to determine whether the phone is call waiting capable) comes in along with the CID data before any phone is taken off hook and then as soon as the first phone goes off hook, it immediately responds to or ignores the query?
This is from the patent you referenced (emphasis mine):
Call waiting-caller ID is used to notify a user currently on a first call of a waiting second phone call to the same phone number (call waiting). A telephone may be off-hook and connected to a first phone call. When there is another incoming call to that telephone number, a central office switch sends two consecutive call waiting indication signals. If the telephone is attached to a caller ID box, that caller ID box sends back an acknowledgement signal to the central office switch after receiving the first call waiting indication signal. If the central office switch hears this acknowledge signal from the caller ID box within a certain amount of time, it will send tones to the caller ID box that represent the name and number of the second caller.
Based on that, I think the answer to your question is no.
It would seem that if that sort of handshaking was postponed until an actual second call did come in, that a non call waiting phone would pass that (initial query) audio burst through to your ear.
In my experience, call waiting service makes a beep to let you know that a second call is coming in. Maybe the call waiting ID query doubles as the beep.
Also, like you say, if more than one Call waiting capable phone was off hook, they would all respond.
That might be rare enough that it was deemed acceptable.


Finest regards,
Bill Root
Ascendis Software LLC