Obi202 expectations from a newbie

[tns1]

The Obi echo test# does not sound particularly clear. There is a background hiss I wouldn't want to hear all the time. If this is indicative of call quality, do users find that adding a filtered phone cord helps?

I notice that some have posted latency #s for their actual connections. Is there some tool or automated method to measure this?  Short of calling all your friends and a bunch of random 800 numbers in different states, are there numbers that will give an automatic callback with a recording? I seem to remember something like this existing.

[SteveInWA]

I wouldn't draw any conclusions about audio quality based on the echo test.  Again, just sign up for service with an ITSP and try it out.  Your only risk is the pittance you'll pay for service -- either you'll be thrilled, or not, at which point you can cancel it.

There is more to VoIP call quality than latency.  If you want to test your internet connection's suitability for VoIP, use the G.711 CODEC test on this website:

http://myspeed.visualware.com/index.php

A MOS of 4.0 or above is fine; anything below that indicates a problem with your ISP's service.

[202Owner]

The Obi echo test# does not sound particularly clear. There is a background hiss I wouldn't want to hear all the time. If this is indicative of call quality, do users find that adding a filtered phone cord helps?

Noise is not entering in the middle of the transmission... it's just packets of data traveling across the Internet.  If you only hear the noise when calling a particular destination, then you could assume the noise is entering from that end... not your problem.  If you don't hear the noise calling from one OBi PHONE jack to the other, then I would not worry about noise.  If you do hear noise, then consider your own phone equipment and wiring.  I doubt the analog side of the OBi is noisy.

And welcome to your new hobby! 

[tns1]

I signed up for an Anveo 'free!' acct and obtained a local number for testing (total outlay $4.80). I used the ObiTalk portal rather than the direct manual method. I am not sure this saved me any confusion, since most of the how-tos seem to be written for manual method. I kept my Obitalk acct open on one window, while I walked thru the Anveo signup on another. There seems to be slight differences in terminology that had me questioning what data went where, but I did get it working. It took 6hrs for the Paypal payment to reach Anveo before I could make calls.

My reading suggests that the Obitalk portal (if you use it), will refresh the Obi settings every so often. Is this because these settings are subject to corruption, or that Obihai continues to tweak what it considers a good setup, or what? Why would I want to stick with Obitalk vs a manual (static) setup which seems more secure? 

After setup, I made a few local, long distance, and toll free calls to test outgoing, and made a few calls from another house phone to test incoming. I find that the call quality is good. I do still have a slight background hiss present on all calls, but it is less offensive now that I began using a modern cordless handset, rather than the old corded one I had laying around.

One thing I didn't expect is that the call quality during Anveo voicemail retrieval(local) is really bad. I am referring just to the robo voice that guides you thru your messages, and not the actual recorded message content (which sound fine). The robo lady's voice quality is harsh, noisy and she seems to drop syllables and not speak in complete sentences. I think this dialog may be done with text to voice, as opposed to an actual recording. When someone calls in, the canned voicemail greeting is of good quality. I don't plan on using VM, but I may want to use a telemarketer screener (require a code entry to reach answering machine), so I may be using that call flow tool.

[SteveInWA]

If you go back and read your original post, your goal was to replace your Plain Old Telephone Service (POTS) with the closest VoIP equivalent.  We described how to do that, with the least amount of effort or opportunity for error.

Obihai's product line is designed to appeal to, and to be successfully set up by, several types of users, with a choice of interfaces.  There is no one best method. 

The OBiTALK web portal is geared toward simplicity of basic setup, while also offering access to "expert mode" advanced settings.  It also supports a provisioning API for SIP VoIP service providers, to emulate the sort of "hands off" setup and management performed by large cable companies, or pure-play VoIP providers like Vonage.  Obihai isn't "tweaking" or changing configuration settings remotely.  The only thing they do is push firmware updates, if you so desire.  This makes sense for the users in this scenario.

SIP ITSPs have always faced a problem:  They can offer metered (per-minute, or buckets of minutes) outbound calling, with open SIP credentials that can be used on as many different SIP user agents (hardware ATA or softphone) as the user desires.  Or, they can offer "unlimited" (subject to anti-abuse restrictions) calling, on a device with locked-down SIP credentials, to try to protect their service from fraudulent usage (one paid plan, being used by multiple users).  The managed ITSP offerings via OBi were designed to help ITSPs with offering various service plans, optionally including a locked-down option for unlimited use.

The perceived security risk of using the portal is insignificant, as long as you use strong passwords for your OBiTALK portal account, and for your device admin, and for your SIP registrations.

The OBi device's local web server interface is geared toward technically-competent individual users, "enthusiast" or "hobbyist" users, and to business or carrier service providers, who want or need to create and maintain custom digit maps, dial plans, and other advanced options.

Again:  you wanted "set it and forget it" service.  I think we've given you that solution.  It's your choice. 

[tns1]

Thanks for the info. Many new concepts for me. If I understand you, the reason to use the Obitalk portal to provision my 202 is that it simplifies setup, prevents accidental changes, and prevents abuse by 3rd parties potentially costing me and/or my provider. That all sounds good to me. My goal of replacing a basic POTS line has not changed, and with my limited testing it looks like the Obi202 could do that very well. This doesn't mean I don't want to understand the security risks, or that I might not want more out of it in the future.

In the SIP scanner thread it is mentioned that Obihai uses one or more of the scan prevention methods (Oleg) for providers it recommends. I looked at the relevant settings with Obi Expert, and based on the thread I am not seeing that. My unused SPn services are still enabled, and my X_InboundCallRoute is still {ph1}. The only thing I see is that my X_UserAgentPort does not begin with 506.

I don't really know how the SIP scan exploit works, but it sounds like a good thing to prevent. Are these SIP scan remedies still a good idea to implement? If so, why were they not part of the basic provisioning? Is this only done for the Obitalk/Anveo annual plan? Did I do something incorrectly during setup?

thanks

[SteveInWA]

The settings described in that thread are not defaults, and the majority of users don't experience this exploit.  If you're concerned about it, you can add the modifications yourself; properly typed in, it won't hurt anything.

No doubt, someone will disagree with me, but in my own opinion, the only real-world risk of a SIP scanner is that somebody clever enough to exploit a SIP scan would at worst make some phone calls using your account, which you would eventually discover yourself.  They're not going to be stealing your bank account information.  They're looking for larger enterprise PBX installations where it might be worth the effort to use the system for large-scale robocalling.  These days, SIP trunks are so cheap that trying to exploit someone else's account is rather pointless.  The main reason to deal with it is if/when you start receiving annoying calls from fake scanner numbers.