News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Call Waiting Dropping Call

Started by pc44, June 20, 2011, 06:44:10 PM

Previous topic - Next topic

pc44

Hi guys,

I am having a problem where every time someone tries to call me while I am already on the phone, I lose both calls.  I really don't want to disable call waiting in the obi and am hoping you might have some idea as to what is wrong here.

When the second call comes in, I hear the beep on the line, and then the caller id information for the second call is displayed on my phone.  Right after that (before a 2nd beep), I lose my original call and second call as well.  Below are the pertinent entries for the latest occurrence.  Thanks for any help you can offer.

Call 1   06/20/2011    17:45:18   
Terminal ID   GoogleVoice1   PHONE1
Peer Name      
Peer Number   1855496xxxx   
Direction   Inbound   Inbound
17:45:18   Ringing   
17:45:24   End Call   
Call 2   06/20/2011    17:11:43   
Terminal ID   PHONE1   GoogleVoice1
Peer Name      
Peer Number   1800876xxxx   1800876xxxx
Direction   Outbound   Outbound
17:11:43   New Call   
17:11:47      Call Connected
17:45:24      End Call

ProfTech

I have Google Voice set up on my system only so I can have a local number for my daughter to call [and for testing possible future use] so haven't used it a lot but from looking at your log it looks to me like this may be either an issue with Google Voice itself or an interaction between them and the Obi. You're involved in a Google Voice call and another call comes to the same Google Voice number, correct? It almost sounds like call waiting might not work with Google Voice. You might try turning off call waiting in the Obi as a test and see if the second call rolls to Voice mail at Google. There may not be anything Obi can do to prevent this situation.

pc44

Thanks for the reply ProfTech.

You might be right.  Yes, these are both Google Voice telephone calls.  When using Google Voice with other forwarded telephones, I have not had this problem in the past with call waiting.  In the past, I could put the first call on hold and answer the incoming call waiting call without losing the first call.  But with my Obi, I lose both calls now.  If I have no other choice, I will follow your advice and disable the call waiting feature in the Obi.

Thanks again for your input!

jimates

The Obi (and google voice) is supposed to support 2 simultaneous sessions per account.

If you can, set up another google voice number on sp2 and test with an incoming call on sp2 while an active call on sp1, and see if the same thing happens.

pc44

Hi jimates!

Thanks for the reply.  I actually have 2 obihai 100s in use here.  One is in use with google account no. 1, and the other is in use with google account no. 2.  Yet, this call waiting problem happens on 'both' of my obihai 100s and both google voice accounts.

However, I will follow your advice and let you know of my results.  Thanks for the idea.

pc44

Quote from: jimates on June 21, 2011, 04:41:04 PM
The Obi (and google voice) is supposed to support 2 simultaneous sessions per account.

If you can, set up another google voice number on sp2 and test with an incoming call on sp2 while an active call on sp1, and see if the same thing happens.

I called Google Voicemail and kept the connection active on line 1.  Then, I called the second Google Voice Number from a landline and did not lose my original connection.

So I am still not sure what the problem is.  Only when calling the same number/line do I lose both calls immediately before the second ring.

LeftRight

Are you running latest 2384 firmware?

It does not seem to happen on my GV calls. After I hear the beep and see the second CallerID on my phone, I simply press hook-flash button and talk to the second caller, and I hookflash again, I get back to the first caller immediately.

In your case, did you hookflash to switch to the second call? or both call were just terminated without doing anything?

pc44

Hi LeftRight!

Thanks for your post.  Yes, I wish my setup was working like yours.  In my case, both calls are terminated without doing anything.  This is not an intermittent problem and can be reproduced consistently.

Regarding the firmware, I am at 1.2.1 (Build: 2289).  As far as I understand, this build does allow for auto-updating via the telephone console.  However, when I pick up the line and press ***6, I get the following verbal message: "Software update not available."

Is build 2384 official already?  If so, I wonder why it will not come down via ***6.

RonR

2289 is the latest 'official' release and the only one that can be installed via ***6.

2384 is technically a pre-release, but it's very stable and fixes a number of significant bugs present in 2289.

2384 has to be downloaded from here:

http://www.obihai.com/firmware/OBi-1-2-1-2384.fw

and installed locally.

LeftRight

#9
I downgraded my unit to 2289, and it worked fine too.

2384 is still a test firmware at the moment, and you may download it first, then manually upgrade your unit through web-browser. *** 6 does not apply until it becomes a official release later on.

You may try 2384 first, and see if problem remains. If the unit still behaves the same on GV call waiting, you might try on other voice services ...

You can easily test call waiting feature on OBiTALK service, and here are the steps (with 2 OBi units) --

1) OBi100 (1) calls into **9 - 222 222 222 (echo test)
2) OBi100 (2) places a call to OBi100 (1)
3) OBi100 (1) will hear a beep, then, see the callerID on the phone (callerID is the OBi number of OBi100(2))
4) OBi100 (1) hits hookflash, and talks to OBi100 (2)
5) OBi100 (1) hits hookflash again, and gets back to echo test.

If this works, then, we narrow down the problem to GV. One way we can do is to factory reset your unit, and check over all GV settings, hopefully we don't need to go this far ...

pc44

#10
Thanks RonR and LeftRight for your input.

LeftRight, I followed your instructions but get mixed results.  Sometimes I lose both calls without doing anything.  Other times, I only lose the incoming call waiting call.  Either way, I am consistently not able to pick up the incoming call waiting call, even though the caller id is displayed for the incoming call.

The syslog is attached because the forum will not allow me to post it due to its length.

You'll notice this section beginning at 15:38:53.763:
<7> [DSP]: ---- H/W DTMF ON (level:3) : 1 @ 78573210 ms---- 192.168.1.152 22/06 15:38:53.763
<7> [RTP] DTMF TX (RFC) -- dgt: 1, c_dgt: 192.168.1.152 22/06 15:38:53.772
<7> [DSP]: ---- H/W DTMF OFF @ 78573250 ms ----
192.168.1.152 22/06 15:38:53.802
<7> TCP:Broken Connection(xmpp) 32 -1
192.168.1.154 22/06 15:38:55.242
<7> XMPP:State changed from: 14 to:16
192.168.1.154 22/06 15:38:55.243
<7> RTP:Del Channel
192.168.1.154 22/06 15:38:55.244
<7> GTT:xmpp service down: -998
192.168.1.154 22/06 15:38:55.245
<7> XMPP:restarting node:500
192.168.1.154 22/06 15:38:55.246


Thanks!

LeftRight

Hi pc44, your SYSLOG does tell a lot of things, and here are my findings -

1/ Are you running 2384? If not, please upgrade your unit to this version, otherwise, we won't know whether it is known problem, and possibly got fixed in 2384 already ..

2/ Your GV calls got dropped a couple of time, and reason seems to be TCP broken (from your log). Are you using SSL option for GV?

    You may first remove GV from your unit, and then repeat the call waiting test on OBiTALK, using exact steps that I posted, see if that is OK.

    All I can see from your log is that, you call **9 - 222 222 222, then, you have another GV call into your unit, then, GV call got terminated because of XMPP connect broken. So, please remove GV from your unit, and just use another OBi100 to do the call waiting test.


pc44

Hi LeftRight,

I was not running firmware 2384 since it was not yet official.  However, I have followed your advice, and 1.2.1 (Build: 2384) is now installed on the Obi.

Interestingly, I got xmpp errors immediately after the reboot that came after the firmware update.

<3> SYSTEM REBOOTED (Reason: 4, lifecycle: 174)
192.168.1.154 23/06 06:43:20.055
<0> SLIC_init ... 192.168.1.154 23/06 06:43:20.056
<0> Reset SLIC... 192.168.1.154 23/06 06:43:20.056
<150> Setup Provisioning for system start! 1800
192.168.1.154 23/06 06:43:20.057
<0> SLIC & DAA is initialized 192.168.1.154 23/06 06:43:20.773
<6> Start Main Service Now 192.168.1.154 23/06 06:43:22.837
<7> Voice Main
192.168.1.154 23/06 06:43:22.838
<7> [CPT] --- FXS s/w tone generator (ringback) ---
192.168.1.154 23/06 06:43:22.844
<7> BASESSL:load cert:5
192.168.1.154 23/06 06:43:22.951
<7> BASESSL:Load certificate ok
192.168.1.154 23/06 06:43:22.957
<7> XMPP:State changed from: 0 to:1
192.168.1.154 23/06 06:43:23.000
<7> GTT:Init xmpp node ok
192.168.1.154 23/06 06:43:23.002
<7> ++++ open socket; bind error (c0a8019a:5061), rc=-264, s=7
192.168.1.154 23/06 06:43:23.002
<7> XMPP:Invalid cfg use for xmpp
192.168.1.154 23/06 06:43:23.003
<7> GTT:xmpp not configured
192.168.1.154 23/06 06:43:23.003
<7> [SLIC]:Slic#0 ON HOOK
192.168.1.154 23/06 06:43:23.955
<7> [CPT] --- FXS s/w tone generator (sit_1) ---
192.168.1.154 23/06 06:43:29.986
<7> [CPT] tone compression done - 12293 !!
192.168.1.154 23/06 06:43:35.135
<147> PROV: Auto Update invalid server name()
192.168.1.154 23/06 06:43:37.127
<7> [PR] prompt transcoding done!!
192.168.1.154 23/06 06:45:13.679


After performing another test, this time with Google Voice SP1 Disabled and dialing using only ObiNumbers, I am able to keep the first call, if I do nothing.  If I try hookflash, I am successfully connected to the incoming call waiting call.  However, when I tried to hookflash back to the first call, I lost both calls.  Perhaps this is normal.  The pertinent syslog is attached.

Thank you for your help with this!

LeftRight

No, hookflash will NOT end either calls, it just allows you to between two calls.

Here is my explanation on why two calls both terminated after you hit second hookflash

- First call was terminated may have something to do with OBi-222 222 222, since it has been 60+ seconds after you call into this echo test number, and somehow OBi-222 222 222 terminates you call

- Second call was terminated because your OBi100 (2) hung up. I can see that, right before you press second hookflash, your OBi100 (2) went on-hook, then, the second call was terminated. after you hook flash, you only hear fast busy tone.

You may do one more test without doing anything on your OBi100 (2), no DTMF, and just talk, and see if the call is terminated.

If this test goes OK, then, you should have call waiting working on GVs too.

pc44


Unfortunately, here are my results :(

I did the same test.  I connected on my Obi100 (#2) to the echo line 222 222 222 and just kept talking.  Then, while I was talking and hearing my echo, I used my Obi100 (#1) to make the call to the ObiNumber of my Obi100 (#2).  I kept right on talking and did not enter any DTMF this time at all.  However, when I eventually did hookflash to the incoming call waiting call and then hookflashed back to the original call, I lost the call again.

Updated syslog attached.

LeftRight

This seems more to me a network issue. what kind of router are you using? Do you have a speed test on your home network? sufficient to allow you two simultaneous calls?

If you can open call status during a call, do you see any packet loss?

If you have a spare home router, you may replace current one, and test whether it gets better with a new router. Also, you may take the device to another place to try out, your friends' home network ...

Also, you may get assistance from OBIHAI support at support@obihai.com ...

pc44

Hi LeftRight,

Thanks again for your helpfulness!  A Speedtest provides the following:
Download Speed: 2874 kbps (359.3 KB/sec transfer rate)
Upload Speed: 731 kbps (91.4 KB/sec transfer rate)

The home network is mostly gigabit ethernet with the router only at fast ethernet.  The router is a Westell 7501.  Before the Obi100s, I was using Google Voice via a Linksys SPA2102 in conjunction with this same router.  At that point, two simultaneous calls were possible.  I am getting 0% packet loss during a test call that I just performed.

However, I think you might be barking up the right tree.  I plan on looking further into this possibility of a network issue at fault here.  I will keep trying to find the answer here.  I will disable call waiting on Obi #1 but keep call waiting enabled on Obi #2.  I need to have at least one reliable line.

Thanks again, LeftRight, for ALL of your help.  It is appreciated.  If anyone has any other ideas for me based on my previous posts and attached logs, any suggestions are appreciated.

loan

I didn't see this thread before and started my own, but I will link and repeat here.

UPDATE:  I got a new OBI 110 from amazon.  the CW issue STOPPED.  Well then a few hours later I let it upgrade the firmware to 2384.  Problem is back.
I'm stupid and didn't think to see what version it was on before.  I downgraded to 2289, problem still there.  I don't have any firmware before that, so maybe the 1.20 versions might be ok.  Maybe I need to order another one that has old firmware and keep it that way until this is resolved. 

No responses from obi folks?


http://www.obitalk.com/forum/index.php?topic=1151.msg7238#msg7238

   
obi + ooma + port 443
« on: July 10, 2011, 02:13:24 PM »
Quote  Modify  Remove
This issue has been driving me nuts.  First a brief background, and then what I think the issues are.  Hopefully you experts out there can help me in the right direction.  I've searched and have not found a similar issue.

Background (so that others can save time if they have similar issues):
After switching to Charter cable modem service, lots of problems.  It seems to relate to how charter handles DHCP.  I tried 6 different routers and 3 different cable modems, and the issue is that charter has very short IP leases, and when renewing IPs, almost all the current routers I had, dlink, linksys, trendnet, netgear, plus a dlink running dd-wrt--had problems renewing the ip address.  They all got 0.0.0.0. Once the problem happens, even power cycling of both devices does not help unless one follows a very convoluted sequence of booting up the devices.  (just google charter dhcp renew issue and you will see).

However, 1 router, Verizon/Westell 7501 will get an IP almost immediately.  Even after simulating a power outage by turning both off and on at the same time, things will get back up and running (unlike any of the other routers above).  Please take my word that I've used a lot of different equipment w/ different providers, and this is the first time I've seen anything like this.

So, now if I don't want the internet going down all the time, I have to use this Westell/VZ router.  That leads me to the OBI problem.


Network setup:
Cable modem -->> VZwestell7501 port 1---->>obi 110  --- phone set1  (SIP1 = google voice/googletalk= default, sip2=callcentric)
                                              port 2 ---->>ooma hub --- phone set 2
                                              port 3---->>PC

ie, I have ooma and obi set up so that I can have 2 different, independent phone lines if you will.  (I am NOT connecting the ooma to then line port, just for clarification).  The 2 devices share a single internet connection through the same router though.

I started getting random disconnects when using the phone connected to the obi.
scenario 1: on the phone w/ obi connected phone, call waiting comes in
   a) answer cw-->>disconnects call1 and just get dial tone
   b) ignore cw --->> after a few rings, obi will disconnect call1 anyway


scenario 2: use obi phone to call ooma phone. no problem.

scenario 3: use ooma phone to call obi phone: PROBLEM: immediate loss/disconnection when obi phone answers.

scenario 4: use obi phone to call a number outside of my network, then make a call w/ ooma phone with obi phone still connected to other number.  no problem.

scenario 5: use ooma phone to call a 3rd number, try to make a call w/ obi phone:  PROBLEM: number rejected by service provider error 500.
  a) while connected w 3rd party w/ ooma phone, use obi phone to call, but now use SIP2 (ie not google). no problem.
  b) while connected w 3rd party w/ ooma phone, make call w/ google talk on computer. no problem.

scenario 6: call 3rd party w/ googletalk on pc, call another number w/ obi, no problem.

MY conclusion is that there is something odd with this router, PLUS there is some interaction between the ooma and googletalk on obi that is causing this issue.  Oddly enough, the other routers don't have this problem.

What I understand is that both OOMA and Googletalk use TCP ports 53 and 443. Apparently the combination above somehow confuses the router or obi and calls cannot be made.  It seems related to scen 1 and 2 above, but of that I'm less certain.

Because using googletalk on a pc does not seem to bother the obi, I blame the ooma.  But, because other routers don't cause this problem, I blame this router.  However, because the ooma doesn't seemed bother by anything here, I blame the obi.  See how confused I am?

Hopefully I have detailed enough information here that someone else can verify the issue exists and is repeatable outside of my network.  I suspect if it can be repeated that it is more generalized than just an ooma/westell issue and may have to do with how googletalk, obi, and port 443/53 interact.  In case a similar issue arrises with different equipment.

Thanks.

coldwater

I noticed the same thing. I use obi100 and updated to the newest software. My setting is SP1 from google voice, SP2 is from GV+Sipgate+sipsorcery. The second call from call waiting will drop my current call if the 2nd comes through SP1 (GV directly). Call waiting will not drop the carrent call if the 2nd call comes through from SP2.

OBiSupport

Hi Coldwater,

We like to diagnose the problem that you are experiencing, would you please contact OBi support at support@obihai.com, and state your 9-digit OBi number in the email? We will help you from there,

Thanks,