Call Waiting Dropping Call
pc44:
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:
Code:
<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.
Code:
<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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page