Make Obi110 work better on Low Bandwidth/High Latancy (Afghanistan)
PortableTech:
Greetings All,
I am in Afghanistan and had to just short of sell my soul to get a really bad internet connection. This service is provided by a company called IO-Global. I am currently using an MBR-1200 Cradlepoint router, which is handling the pppoe connection to IO-Global.
Their connection feeds into an oversold satellite connection. Per advertising I am promised 128k/64k but usually does not do quite that well. Latency is typically around 600ms-700ms. The Obi is hooked up and seems to work fine. I can call my wife, and the call will be perfect for about 30 seconds, then it will go to dead silence for about 30 seconds and then I get a dial tone again. I can call right back with no problem, but the same situation seems to occur.
The questions I have is, does this problem sound like it would be resulting from a specific situation? And secondly, are there changes in general which I can make to the Obi settings to better allow it to handle a low bandwidth/high latency connection? Oh, and for reference, the only calls I am making right now are Obi to Obi calls. I have not even programed any SIP settings into my Obi here in Afghanistan yes.
Thanks for any thoughts, advice, or recommendations you can provide.
--PortableTech
PortableTech:
Sorry, the Tech side of me got a little off track there and did not really make that good an effort to help resolve the problem. So, I setup a Syslog server and captured from startup of the unit through a call and it's failure. Perhaps this will help.
--PortableTech
Code:
2011-10-13 18:04:56 Local2.Alert 192.168.0.195 Reboot is scheduled in 1 seconds
2011-10-13 18:04:57 Kernel.Emerg 192.168.0.195 Reboot checking.....
2011-10-13 18:04:57 Kernel.Emerg 192.168.0.195 Final Cleanup before reboot....
2011-10-13 18:05:03 Local2.Emerg 192.168.0.195 Goodbye! Reboot Now. (reason: 9)
2011-10-13 18:05:09 Kernel.Info 192.168.0.195 ==== Networking is ready ====
2011-10-13 18:05:09 Kernel.Emerg 192.168.0.195 IP Address= 192.168.0.195
2011-10-13 18:05:09 Kernel.Emerg 192.168.0.195 Gateway = 192.168.0.1
2011-10-13 18:05:09 Kernel.Emerg 192.168.0.195 Netmask = 255.255.255.0
2011-10-13 18:05:09 Kernel.Error 192.168.0.195 SYSTEM REBOOTED (Reason: 9, lifecycle: 177271)
2011-10-13 18:05:09 Local5.Notice 192.168.0.195 ZT: CustomID 1
2011-10-13 18:05:09 Kernel.Emerg 192.168.0.195 SLIC_init ...
2011-10-13 18:05:09 Kernel.Emerg 192.168.0.195 Reset SLIC...
2011-10-13 18:05:09 Local2.Info 192.168.0.195 Setup Provisioning for system start! 1100
2011-10-13 18:05:09 Local2.Info 192.168.0.195 Setup Provisioning2 for system start! 1300
2011-10-13 18:05:10 Kernel.Emerg 192.168.0.195 SLIC & DAA is initialized
2011-10-13 18:05:12 Kernel.Info 192.168.0.195 Start Main Service Now
2011-10-13 18:05:12 Kernel.Debug 192.168.0.195 Voice Main
2011-10-13 18:05:12 Kernel.Debug 192.168.0.195 [CPT] --- FXS s/w tone generator (ringback) ---
2011-10-13 18:05:12 Kernel.Debug 192.168.0.195 BASESSL:load cert:5
2011-10-13 18:05:12 Kernel.Debug 192.168.0.195 BASESSL:Load certificate ok
2011-10-13 18:05:13 Kernel.Debug 192.168.0.195 XMPP:Invalid cfg use for xmpp
2011-10-13 18:05:13 Kernel.Debug 192.168.0.195 GTT:xmpp not configured
2011-10-13 18:05:13 Kernel.Debug 192.168.0.195 XMPP:Invalid cfg use for xmpp
2011-10-13 18:05:13 Kernel.Debug 192.168.0.195 GTT:xmpp not configured
2011-10-13 18:05:14 Kernel.Debug 192.168.0.195 PROMPT:UsrBankChksumErr
2011-10-13 18:05:14 Kernel.Debug 192.168.0.195 ++++ user prompt corrupted
2011-10-13 18:05:15 Kernel.Debug 192.168.0.195 [SLIC]:Slic#0 ON HOOK
2011-10-13 18:05:16 Kernel.Debug 192.168.0.195 +++++ Onhook while onhook
2011-10-13 18:05:17 Kernel.Debug 192.168.0.195 [DAA]: FXO ONHOOK MONITOR
2011-10-13 18:05:20 Local2.Info 192.168.0.195 PROV: Start to download files ...
2011-10-13 18:05:20 Local2.Error 192.168.0.195 PROV: Invalid server name, Skipped
2011-10-13 18:05:20 Kernel.Debug 192.168.0.195 [CPT] --- FXS s/w tone generator (sit_1) ---
2011-10-13 18:05:22 Local2.Info 192.168.0.195 PROV: Start to download files ...
2011-10-13 18:05:23 Kernel.Debug 192.168.0.195 TCP:Connect OK(HTTP GET)15
2011-10-13 18:05:25 Kernel.Debug 192.168.0.195 [CPT] tone compression done - 12523 !!
2011-10-13 18:05:28 Local2.Info 192.168.0.195 PROV: Update Config Now, itsp:0...
2011-10-13 18:05:28 Local1.Emerg 192.168.0.195 XML_parse_prov 0
2011-10-13 18:05:28 Local2.Info 192.168.0.195 Same version: Skipped (2)
2011-10-13 18:05:28 Local2.Info 192.168.0.195 PROV: Start to download files ...
2011-10-13 18:05:28 Kernel.Debug 192.168.0.195 TCP:Connect OK(HTTP GET)17
2011-10-13 18:05:30 Local2.Info 192.168.0.195 PROV: Update Config Now, itsp:0...
2011-10-13 18:05:30 Local1.Emerg 192.168.0.195 XML_parse_prov 0
2011-10-13 18:05:30 Local2.Info 192.168.0.195 Same version: Skipped (2)
2011-10-13 18:05:30 Local2.Notice 192.168.0.195 We will check OBt config in 3600 s
2011-10-13 18:05:45 Kernel.Debug 192.168.0.195 [SLIC]:Slic#0 OFF HOOK
2011-10-13 18:05:45 Kernel.Debug 192.168.0.195 off hook
2011-10-13 18:05:45 Kernel.Debug 192.168.0.195 FXS:Stop Ring
2011-10-13 18:05:45 Kernel.Debug 192.168.0.195 FXS:New State:dialing
2011-10-13 18:05:45 Kernel.Debug 192.168.0.195 FXS: State=dialing, flags=0
2011-10-13 18:05:45 Kernel.Debug 192.168.0.195 FXS:Start Tone dial
2011-10-13 18:05:45 Kernel.Debug 192.168.0.195 [CPT] --- FXS h/w tone generator (dial)---
2011-10-13 18:05:49 Kernel.Debug 192.168.0.195 [DSP]: ---- H/W DTMF ON (level:1) : 2 @ 36530 ms----
2011-10-13 18:05:49 Kernel.Debug 192.168.0.195 [DSP]: ---- H/W DTMF OFF @ 37060 ms ----
2011-10-13 18:05:49 Kernel.Debug 192.168.0.195 FXS:Stop Tone
2011-10-13 18:05:58 Kernel.Debug 192.168.0.195 speed dial gives = **920092XXXX
2011-10-13 18:05:58 Kernel.Debug 192.168.0.195 FXS:New State:invalid
2011-10-13 18:05:58 Kernel.Debug 192.168.0.195 FXS: State=invalid, flags=0
2011-10-13 18:05:58 Kernel.Debug 192.168.0.195 FXS:Start Tone reorder
2011-10-13 18:05:58 Kernel.Debug 192.168.0.195 [CPT] --- FXS h/w tone generator (reorder)---
2011-10-13 18:05:58 Kernel.Debug 192.168.0.195 FXS:New Call:**9ob20092XXXX
2011-10-13 18:05:58 Kernel.Debug 192.168.0.195 FXS:New State:incall
2011-10-13 18:05:58 Kernel.Debug 192.168.0.195 FXS: State=incall, flags=1
2011-10-13 18:05:58 Kernel.Debug 192.168.0.195 FXS:Stop Ring
2011-10-13 18:05:58 Kernel.Debug 192.168.0.195 FXS:Stop Tone
2011-10-13 18:06:03 Kernel.Debug 192.168.0.195 SIP_TS:Retx, next in 100
2011-10-13 18:06:04 Kernel.Debug 192.168.0.195 FXS: State=incall, flags=2
2011-10-13 18:06:04 Kernel.Debug 192.168.0.195 FXS:Stop Ring
2011-10-13 18:06:04 Kernel.Debug 192.168.0.195 FXS:Start Tone ringback
2011-10-13 18:06:04 Kernel.Debug 192.168.0.195 [CPT] --- FXS h/w tone generator (ringback)---
2011-10-13 18:06:08 Kernel.Debug 192.168.0.195 RTP:DtmfTxMtd:1(1),0
2011-10-13 18:06:08 Kernel.Debug 192.168.0.195 FXS: State=incall, flags=4
2011-10-13 18:06:08 Kernel.Debug 192.168.0.195 FXS:Stop Ring
2011-10-13 18:06:08 Kernel.Debug 192.168.0.195 FXS:Stop Tone
2011-10-13 18:06:08 Kernel.Debug 192.168.0.195 RTP:Start->43b4838d:11100(80);4cfcf8;0;0:0:0;1(20)
2011-10-13 18:06:10 Kernel.Debug 192.168.0.195 RTP:PeerRflxAddr=43b4838d:11100
2011-10-13 18:06:11 Kernel.Debug 192.168.0.195 RTP:Start->6167feb3:44862(80);0;0;0:0:0;0(20)
2011-10-13 18:06:12 Kernel.Debug 192.168.0.195 RTP:PeerRflxAddr=6167feb3:44862
2011-10-13 18:06:16 Kernel.Debug 192.168.0.195 [DSP]: ---- H/W DTMF ON (level:3) : 1 @ 64090 ms----
2011-10-13 18:06:16 Kernel.Debug 192.168.0.195 FXS:CallCmd:digit (4)
2011-10-13 18:06:16 Kernel.Debug 192.168.0.195 [RTP] DTMF TX (RFC) -- dgt: 1, c_dgt:
2011-10-13 18:06:17 Kernel.Debug 192.168.0.195 [DSP]: ---- H/W DTMF OFF @ 64550 ms ----
2011-10-13 18:06:27 Kernel.Debug 192.168.0.195 RTP:DtmfTxMtd:1(1),0
****
**** This is where we were talking, and about half way to the next message it went dead silent.
****
2011-10-13 18:07:18 Kernel.Debug 192.168.0.195 SIP_TS:Retx, next in 100
2011-10-13 18:07:19 Kernel.Debug 192.168.0.195 SIP_TS:Retx, next in 200
2011-10-13 18:07:20 Kernel.Debug 192.168.0.195 SIP_TS:Retx, next in 400
2011-10-13 18:07:24 Kernel.Debug 192.168.0.195 SIP_TS:Retx, next in 800
2011-10-13 18:07:30 Kernel.Debug 192.168.0.195 [PR] prompt transcoding done!!
2011-10-13 18:07:32 Kernel.Debug 192.168.0.195 SIP_TS:Retx, next in 1600
2011-10-13 18:07:48 Kernel.Debug 192.168.0.195 SIP_TS:Retx, next in 3200
2011-10-13 18:07:49 Kernel.Debug 192.168.0.195 SIP_TS:INVITE Times out
2011-10-13 18:07:49 Kernel.Debug 192.168.0.195 FXS:New State:invalid
2011-10-13 18:07:49 Kernel.Debug 192.168.0.195 FXS: State=invalid, flags=0
2011-10-13 18:07:49 Kernel.Debug 192.168.0.195 RTP:Del Channel
2011-10-13 18:07:49 Kernel.Debug 192.168.0.195 [JB] call overall status --
peer: 97.103.254.179:44862,
local: 192.168.0.195:29386,
pkt_tx: 5030,
pkt_rx: 2468,
bytes_tx: 865196,
bytes_rx: 424496,
clk_diff: -1200 PPM,
pkt_in_jb: 0,
pkt_ooo: 0,
pkt_lost: 5,
pkt_late: 6,
pkt_loss_rate: 0 %,
pkt_drop_rate: 0 %,
jb_len: 230 ms,
curr_rcvd_jitter: 133 ms,
rcvd_digits: 0,
underruns: 6,
overruns: 0,
seq_num_broken: 3,
pkt_interp: 4992,
skew_comp: 56 ms,
frm_in_pkt: 2
2011-10-13 18:07:53 Kernel.Debug 192.168.0.195 [SLIC]:Slic#0 HOOK FLASH
2011-10-13 18:07:53 Kernel.Debug 192.168.0.195 FXS:Stop Tone
2011-10-13 18:07:53 Kernel.Debug 192.168.0.195 FXS:New State:dialing
2011-10-13 18:07:53 Kernel.Debug 192.168.0.195 FXS: State=dialing, flags=0
2011-10-13 18:07:53 Kernel.Debug 192.168.0.195 FXS:Start Tone dial
2011-10-13 18:07:53 Kernel.Debug 192.168.0.195 [CPT] --- FXS h/w tone generator (dial)---
2011-10-13 18:07:56 Kernel.Debug 192.168.0.195 [SLIC]:Slic#0 ONHOOK
2011-10-13 18:07:56 Kernel.Debug 192.168.0.195 on hook
2011-10-13 18:07:56 Kernel.Debug 192.168.0.195 FXS:Stop Tone
2011-10-13 18:07:56 Kernel.Debug 192.168.0.195 FXS:New State:onhook
2011-10-13 18:07:56 Kernel.Debug 192.168.0.195 FXS: State=onhook, flags=0
2011-10-13 18:07:56 Kernel.Debug 192.168.0.195 FXS:Stop Tone
2011-10-13 18:07:56 Kernel.Debug 192.168.0.195 FXS:Stop Ring
QBZappy:
PortableTech,
Not addressing the OBi to OBi directly, however if you don't figure out how to make reliable calls using that approach you may consider the following ideas. Sometimes it is easier to find another way that works rather than breaking your head figuring out. It then becomes a matter for curiosity.
It's not clear what codec OBi to OBi calls use. I was thinking if you want to control the call using the a codec with the lowest bandwidth consumption that the OBi supports, I would test by setting up a free account with any of the following Service Providers and disable all the codecs on the OBi except the G729 Codec. See if forcing call over G729 makes a difference.
Callcentric http://www.callcentric.com/
sip2sip https://mdns.sipthor.net/register_sip_account.phtml
Anveo http://www.anveo.com/
Some interesting tidbits I found that may be of interest from the Callcentric site. Might be applicable to voip in general:
Unlimited in-network calling
In-network calls are always free regardless of your calling plan. Call any other Callcentric member worldwide for free as often as you want.
http://www.callcentric.com/features/unlimited_in-network_calling
Callcentric requires a 28.8K or faster internet connection via modem or broadband. Callcentric recommends a broadband internet connection for best results.
Users with dial-up modem internet connection can use software such as Xten X-Lite or X-Pro. Dialup users will not be able to use telephone adapters.
http://www.callcentric.com/hlp.php?t=int_connection
Just curious, have you tried making a Skype to Skype call? If so, how is the call quality on that call? Trying to gauge OBi vs ISP issues and SIP vs Skype protocol to see if it is at all possible to get good voice communication.
Good luck.
PortableTech:
I had considered the idea of a change in Codec, but had not quite tried going that route yet as it does not feel like a codec issue at this point. To go from crystal clear to nothing on a fairly predictable schedule just does not make me lean that direction, though I may be proven wrong.
In regards to your question of Skype to Skype, the voice side of it works very well, the video side is a little choppy. But I have never had the drop off issues with Skype that I am experiencing with the Obi.
-- PortableTech
hwittenb:
PortableTech,
You mentioned that the Skype audio only calls worked fairly well. When I look at wireshark packet traces of Skype calls and OBiTalk calls the striking thing to me is that the Skype audio packets are much smaller than the OBiTalk audio packets. The packet sizes I saw are:
OBiTalk: 214 bytes each way every 20 ms (all codecs enabled probably uses G711)
Skype: 71 bytes except every 5th time 99 bytes, packets sent every 20 ms each way
Sip: 216 bytes each way every 20 ms (all codecs enabled probably uses G711)
Edit: Sip: 74 bytes each way every 20 ms G729 codec
I tried changing the codec on the OBiTalk call to force G729 and the call wouldn't go thru. One thing you might try is to specify SilenceSupression in the Codec Profile used by OBiTalk. This should significantly reduce the rtp audio stream bandwidth requirement. I don't know if that might introduce other problems.
I would also try the sip G729 codec call using sip as previously suggested.
Navigation
[0] Message Index
[#] Next page