Can't Get Call Waiting to Work on Vonage Line Connected to LINE Port

[Glenk]

I have an OBI110 with Google Voice on SP-1 and a Vonage adapter on the LINE port.  The LINE port (Vonage) is used for inbound calls and SP-1 (Google Voice) is used for outbound calls.  If a call is received on the LINE port and is answered then a second call comes in, I hear the call waiting beep but when I attempt to answer the second call, I get the SP-1 dial tone and can't connect to the 2nd call.  It acts like I am attempting a 3 way call between my phone, the 1st person on the Vonage line and a call to be made on the SP-1 line.

In standalone operation of the Vonage connection (no OBI110), when a call is placed on hold by hookflashing, the word "HOLD" appears next to that caller's number on the Vonage adapter's display.  The display will alternate between the info for the 2 callers (caller ID name & number, number of minutes the connection has been active).  With the OBI110 connected, neither call has the "HOLD" indicator next to the number.

I opened an Obi support case and they suggested performing a double hookflash.  That produces the same result as a single hookflash by presenting the SP-1 dial tone.  Subsequent hookflashes will toggle the phone connection between the LINE port and SP-1.

I've tried setting the phone port to "Send hook flash to PSTN".  That results in the HOLD indicator on the Vonage adapter for the 1st call but still no voice connection to the 2nd caller.  I get a hum on the 2nd caller's line but no voice connection.  The 2nd caller hears low level noise but no voice.  I am unable to flashhook back over to the 1st caller, that call is stuck on hold.

The Software version is 1.3.0 (Build: 2690)

Any suggestions would be appreciated.

[Stewart]

I believe that some electrical property of the Vonage device is confusing the OBi and adjusting one or more Line Port parameters may fix it.

Please look at System Status, PHONE and LINE Port Status and report the values of TipRingVoltage and LoopCurrent under Line Port Status in these three cases:

1. With the system idle (Vonage line on-hook).
2. While an incoming call is in progress.
3. After call waiting beep and a hook flash has been sent (Send hook flash to PSTN is on and Vonage box HOLD indicator is on).

[Glenk]

Thanks for your assistance Stewart.  Below are the statuses that you requested.

1. With the system idle (Vonage line on-hook).
Phone Port Loop Current: 0 mA, Line Port Loop Current: 0 mA

Phone Port TipRingVoltage: 45 V, Line Port TipRingVoltage: -50 V

2. While an incoming call is in progress.
Phone Port Loop Current: 20 mA, Line Port Loop Current: 26 mA

Phone Port TipRingVoltage: 7 V, Line Port TipRingVoltage: -6 V

3. After call waiting beep and a hook flash has been sent (Send hook flash to PSTN is on and Vonage box HOLD indicator is on).
Phone Port Loop Current: 20 mA, Line Port Loop Current: 26 mA

Phone Port TipRingVoltage: 7 V, Line Port TipRingVoltage: -6 V

[Stewart]

I'm very surprised -- the loop voltage and current are completely normal.

The next questions are which side is not passing the audio and why.  Connect a test phone on the line side of the OBi, preferably a line-powered corded one.  For example, using a splitter, connect both the OBi Line port and the test phone to the Vonage adapter.  Then, when you get into the problematic state, pick up the test phone and report whether it can hear and talk to the OBi user, and whether it can hear and talk to the the second incoming caller.  Does the OBi Call Status show anything strange at this time?

Also, do other Vonage hook flash functions work, e.g. can you establish a three-way call on Vonage through the OBi?  (Check the OBi's Call Status and/or your Vonage log to confirm that both legs are really on Vonage.)

[hwittenb]

Glenk,
The call waiting tone comes from the Vonage adapter.  Any chance the OBi is interpreting that tone as a disconnect tone?  

In addition to following Stewart's suggestions, I would run a debug syslog on the OBi to see if that data gives any clue as to what is happening.

I did a call waiting test with a Linksys ata attached to my OBi110 line port.  It worked as it should with a single flash from the phone attached to the OBi.  I had "Send Hook Flash to PSTN" set on the Phone Port.

[jimates]

You have to "hook/flash" twice to access the second call on the line port.

Hook/flash only once is handled locally by the Obi. One time will connect you to the default SP.

You can change it so that hook/flash always goes to the PSTN, but then you won't have call waiting on your SP line, unless after the change a double hook/flash may work for the SP. I am not sure but RonR knows.

Physical Interfaces -> Phone -> HookFlashHandling

[Glenk]

Jimates,

Hookflashing once, twice, 10 times, etc produces the same result in my case.

I got hold of a phone line splitter and connected it at the Vonage box with one leg going to the OBI LINE port and the other going to a telephone handset.  With the phone port configured for "Send Hook Flash to PSTN".  A call was received via the Vonage box and answered on the handset connected to the OBI PHONE port.  A second incoming call produced a call waiting tone on the phone , a single hook flash put the first call on hold (per the Vonage box's display).  There was a hum in the hand set and no voice communication with the second caller. 

At that point, I picked up the receiver of the phone that was connected to the Vonage box via the splitter.  On that phone, I had voice communication with the line that is supposed to be active (not on hold per the Vonage box's display).

It appears that the Vonage box is doing what it's supposed to.  The problem seems to be with the OBI110 since the Vonage box is presenting voice to the OBI LINE port but it's not getting through to the attached phone.  Once the first call is placed on hold, communication between the Vonage box and the OBI ceases.  I've tried more than one phone on the OBI.

[RonR]

Glenk,

The problem may not be limited to the LINE Port/Vonage:


http://www.obitalk.com/forum/index.php?topic=2896.0

http://www.obitalk.com/forum/index.php?topic=243.msg18943#msg18943

[Glenk]

I've been trying to run syslog.  Here is what happens:

-          Opened the OBi's web page (http://192.168.10.3)

-          Navigated to System Management/Device Admin/Syslog and filled in             the 'Server' parameter with 192.168.10.3 and left the 'Port' parameter at 514 .

-          In the Voice Services settings, changed the 'X_SipDebugOption' parameter to 'Log All Messages.'

-          Downloaded syslogd.zip to folder C:\syslog.

-          Unzipped syslogd.zip to the C:\syslog folder which created a file called syslogd.exe.

-          Opened a command prompt window and ran syslogd.exe from C:\syslog (C:\syslog>syslogd.exe).  A file called log.txt was created in the C:\syslog folder.  The file had the following entry "Syslogd is listening to port# 514:"

-          Doing anything with the phone connected to the OBI's PHONE port, does not register anything in the command prompt window.

What am I missing?

[RonR]

-          Navigated to System Management/Device Admin/Syslog and filled in             the 'Server' parameter with 192.168.10.3 and left the 'Port' parameter at 514 .

Set:

System Management -> Device Admin ->Syslog -> Server : (IP address of the PC running syslogd.exe)

[Glenk]

RonR,

Thanks for shedding light on that issue.  Syslog worked when I set the syslog server to the IP address of my PC.  Here are the results when a called a received via Vonage on the LINE port then a second Vonage caller rings in.  The caller ID names and numbers have been altered to protect the innocent. Handle Hook Flash Locally is enabled.


[Mar 31 22:29:14][192.168.10.3]<7> [DAA]: FXO ring on

[Mar 31 22:29:14][192.168.10.3]<7>

• Ring On
  
  [Mar 31 22:29:14][192.168.10.3]<7> FXO:NewTermState:ringing
  
  [Mar 31 22:29:14][192.168.10.3]<7> fxo: cp proceeding
  
  [Mar 31 22:29:14][192.168.10.3]<142> PARAM Cache Write Back(256 bytes)
  [Mar 31 22:29:17][192.168.10.3]<7> ------ caller id (pcm_id: 1) received! ------
  ------
  [Mar 31 22:29:17][192.168.10.3]<7>
• DAA CND 03312229,14041111111,JOE BLOW
  ,,,
  
  [Mar 31 22:29:17][192.168.10.3]<7>
• DAA CND 03312229,14041111111,JOE BLOW
  ,,,
  
  [Mar 31 22:29:17][192.168.10.3]<7> [SLIC] CID to deliver: 'JOE BLOW' 140411
  11111
  
  [Mar 31 22:29:27][192.168.10.3]<7> [SLIC]:Slic#0 OFF HOOK
  
  [Mar 31 22:29:27][192.168.10.3]<7> [DAA]: FXO OFFHOOK
  
  [Mar 31 22:29:27][192.168.10.3]<7> [DAA]: detecting disconnect tone, reinit: 0
  
  [Mar 31 22:29:27][192.168.10.3]<7> FXO:NewTermState:offhook
  
  [Mar 31 22:29:27][192.168.10.3]<7> FXO:Stop Tone
  
  [Mar 31 22:29:27][192.168.10.3]<7> [DAA] FXO ring off
  
  [Mar 31 22:30:43][192.168.10.3]<0> ---------- CWCID acknowledged!! -------------
  --
  [Mar 31 22:30:43][192.168.10.3]<7> [DSP]: ---- H/W DTMF ON (level:3) : D @ 72668
  251 ms----
  [Mar 31 22:30:43][192.168.10.3]<7> [DSP]: ---- H/W DTMF OFF @ 72668261 ms ----
  
  [Mar 31 22:30:53][192.168.10.3]<7> [SLIC]:Slic#0 DOUBLE HOOK FLASH
  [Mar 31 22:30:53][192.168.10.3]<7> FXS:DoubleHookFlash
  
  [Mar 31 22:30:53][192.168.10.3]<7> [DAA]: FXO ONHOOK MONITOR
  
  [Mar 31 22:30:53][192.168.10.3]<7> [DAA]: FXO OFFHOOK
  
  [Mar 31 22:30:53][192.168.10.3]<7> [DAA]: detecting disconnect tone, reinit: 0
  
  [Mar 31 22:30:53][192.168.10.3]<7>
• DAA FXO: ON-HOOK, PARA HANDSET: OFF-HOOK
  
  [Mar 31 22:30:53][192.168.10.3]<7> FXO:NewTermState:line in use
  
  [Mar 31 22:30:53][192.168.10.3]<7>
• DAA FXO: OFF-HOOK, PARA HANDSET: ON-HOOK
  
  [Mar 31 22:31:59][192.168.10.3]<7> [SLIC]:Slic#0 DOUBLE HOOK FLASH
  [Mar 31 22:31:59][192.168.10.3]<7> FXS:DoubleHookFlash
  
  [Mar 31 22:32:14][192.168.10.3]<7> [SLIC]:Slic#0 DOUBLE HOOK FLASH
  [Mar 31 22:32:14][192.168.10.3]<7> FXS:DoubleHookFlash
  
  [Mar 31 22:32:58][192.168.10.3]<7> [SLIC]:Slic#0 ONHOOK
  
  [Mar 31 22:32:58][192.168.10.3]<7> [DAA]: FXO ONHOOK MONITOR
  
  [Mar 31 22:32:58][192.168.10.3]<7>
• DAA FXO: ON-HOOK, PARA HANDSET: OFF-HOOK
  
  [Mar 31 22:32:59][192.168.10.3]<7>
• DAA FXO: ON-HOOK, PARA HANDSET: ON-HOOK
  
  [Mar 31 22:32:59][192.168.10.3]<7> FXO:NewTermState:onhook
  

[malcom]

I'm running into the same problem. Has anyone found a solution to it?