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 Select Expand


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.

[QBZappy]

PortableTech,

I was curious to know if you were able to get your OBi to work to your satisfaction in your environment. I have an OBi in a somewhat similar environment as well. I wanted to know if you had made any tweaks that made a difference.

Best--
QBZappy

[PortableTech]

Greetings,

I was indeed able to get this issue licked once I realized how the heck to set the codec selection for the obitalk service.  For Codec Profile A I specifically disabled the G711U and G711A codec.  Now the Obitalk service defaults to useing Codec Profile A, but you can chance that if needed under Obitalk Service-->CodecProfile.

This resulted in the call using about 30kbps/30kbps when active and the call was just as clear as could be and a good step up from Skype quality.  Now, sadly, I can find no way at all to tell what codec was actually used for the call.  It does not show up in call history or the syslog information, but I am going to contact Obi support and see if they can tell me how to retrieve the info, or at least enable it in the syslog.

If these settings do not work well for you, you may try disabling the higher bandwidth usage codecs one at a time in order of bandwidth usage (it is shown in the codec profile) until either the call stops working, or you get the service level you are looking for.

Hope that helps.

--PortableTech

[QBZappy]

PortableTech,

You can see the codec being used during the call. Look at  Status->Call Status

[PortableTech]

I can see that, and one can compute the bitrate being used, though again, it would be nice if it would just show it clearly.  I still wish that it would log that info with the completed call state, I mean, they log 20 other fields, what's one more...

If I can get this all together, I will purchase a few more OBi's and set them up for the troops out here for so they can make some free calls home.  I think it will all work, just gotta try and get all the logistics together.  Sadly, I do not have enough money to cover everyone on base, but I figgure I can eat the internet, service and equipment for a few months as my way of saying thank you.  At least for the guys in our local command. 

-- PortableTech

[QBZappy]

PortableTech,

Here is an opportunity to sync your needs with those of the Obihai.  Recently they put out a request for beta testers of their new OBiPLUS service. Why don't you submit an email requesting to be a beta tester. I sounds like they would provide units for testing.

Look here:
OBiPLUS Beta Program Announcement
http://www.obitalk.com/forum/index.php?topic=1741.0

QUOTE:
We are looking for qualified candidates to take part in the OBiPLUS beta test program.  After the beta test is complete and OBiPLUS moves into a generally available state, OBiPLUS beta users will continue to receive the benefits afforded to paying customers for a period of one year - a $360 value.  

I've noticed that ShermanObi sneaked in an edit on that offer. Last week it mentioned that the beta testers would continue to receive the service after the testing. They have gone cheap on the offer and are now limiting it to one year.

I think it would be a good opportunity for Obihai to field test the OBiPLUS overseas. This would support the troops, and offer valuable data on the OBiPLUS service, as I'm sure the OBi's will be stress tested in that environment. Who knows, someone may notice this and they may even get a military contract out of this for their effort. (I'll be expecting my commission )

Take care of yourself, and next time you see a Canadian ask them to pony up a Tim Horton's coffee. Send me the tab.

Best--
QBZappy

(Tim Horton's is a Canadian coffee franchise who opened a location for the Canadian troops based there)

[RonR]

I sounds like they would provide units for testing.

Another edit:

Note: Each beta participant will supply their own OBi devices.

[PortableTech]

While I am not sure if I am allowed to go into details about it, I have to give a hats off to Obihai as they have taken care of me in regards to this project I am working on.  Hopefully I will have all the equipment in place in the next 2 weeks and can start reporting some more details about all of the setup.

Still waiting to get final confirmation on the VoIP provider, but we have backup plans in case we run into any issues.  I think this is going to prove a good experience for many people.

--PortableTech