Obi1022 with Obi202 Ringing Issues
drgeoff:
Quote from: eightminobi on June 28, 2016, 04:17:49 pm
What you asked is "did you look at the setting of InboundCallRoute for Obitalk". That question really didn't make sense to me--here's why:
1. There is no global InboundCallRoute setting for "Obitalk". Rather, the InboundCallRoute setting appears on the Obitalk portal under expert configuration for each connected device for an account. As I conveyed extensively, I have two OBi devices: The Obi202 ATA box and the OBi1022 desktop phone. So if you're asking what my "InboundCallRoute for Obitalk" is, I would want to know which device you're talking about (it could be either, my thread concerns both the OBi202 and the OBi1022).
The first time I asked I wrote:
"2. The OBitalk 'Line' has its own InboundCallRoute. Check (on the 1022) that is set to ph. It may have been changed to aa." Your "it could be either" doesn't hold water.
And in a subsequent post I wrote:
"It is the Obitalk InboundCallRoute on the 1022 that determines what happens to calls coming into the 1022 from the Obitalk network to the 1022's Obitalk 9 digit number."
I had also explained earlier in this thread that the Obitalk "line" is on a par with the other SPs. You were au fait that SPs have an InboundCallRoute on each device, so why this excuse about "... no global InboundCallRoute setting for "Obitalk"."
I'm not surprised you are having problems. I am surprised that you say you are an engineer.
SteveInWA:
Quote
There is no global InboundCallRoute setting for "Obitalk".
Yes, there is.
OBiTALK is simply treated as another service provider, just like SP1 through SP2, and, if you have an optional Bluetooth dongle, OBiBT.
See the attached screenshot.
Again, this is totally unnecessary. All you need to do is to follow my instructions from my last post. Define two sub-accounts for each Vitelity DID, and set up one sub-account per DID on each of your two OBi devices.
eightminobi:
SteveInWA,
OK, thank you Steve, you're the first person to bring my attention to that "OBiTalk Service" entry (that screenshot was perfect--thank you for taking and posting that!). That's what I needed to see. So any call routed using the "pp(#########)" syntax is going to go through that OBiTalk Service entry and has nothing to do with SP1 through SP4, yes? That makes sense. I still wouldn't call that "global" (as in a programming variable) because the value you cite is still scoped to the OBiTalk Service--I think it's more accurate to just say that it is the inbound call route for any call handled by the OBiTalk Service, which pretty much means any OBi-to-OBi connection (I believe).
Just to clarify, I did do what you suggested (two sub accounts) and got kickbacks from Vitelity (by "kickback", I mean that Vitelity emails you when a routed call cannot reach its endpoint). I have a support ticket in and they're going to troubleshoot with me tomorrow by making some test calls and following the packets on their end.
But the reason I wanted to know more (and have been asking a lot of questions) about the InboundCallRoute in OBi is that I plan to add several additional OBi1022 devices to my setup, and while Vitelity lets you create any number of sub accounts, it restricts each DID to route to a maximum of two sub accounts only. Vitelity advised I use a PBX if I need to route a DID to more than two sub accounts. The way I figure, my OBi202 is playing the role of a PBX.
eightminobi:
Uncalled for: With that, I hereby will ignore everything else you ever write on this forum...
Quote from: drgeoff on June 28, 2016, 04:17:49 pm
I'm not surprised you are having problems. I am surprised that you say you are an engineer.
SteveInWA:
Look, I respect your interest in learning. I know you want to try to make something out of your OBi, but you've now been at this for four days since your first post in this discussion topic. Let me please just offer some perspective:
The OBi 202 can do lots of tricks, but it is challenging to learn the many quirky ways required to "program" it. It's not as powerful as Asterisk (PBX). The 202 isn't suited to be a "collector/distributor" in and out, when managing multiple (>2) destinations. Routing all your calls from one OBi to another places a dependency on that first OBi. If you are out of town, as you mentioned, with the 1022, depending on the 202 to work, but there's a power outage, internet problem, etc. at the 202's site, then you are SOL.
I could have gotten this running in 10 minutes or so, after first setting up working ITSP extensions or sub-accounts (Granted, your ITSP and their support resources seem to blow in that regard).
The easiest, most reliable, and technically simple solution is to manage the extensions at the ITSP. Local-based PBXing is ok, if you want a hobby, but, considering the advances in cloud-based VoIP telephony, it's outdated and a waste of time.
With just a bit of annoying form-filling, you could switch to, for example, Callcentric, set up as many extensions as you need, and quickly set up "call treatments" to route inbound calls to whichever SPs on whichever OBi devices you control. You can have up to fifty-one (!) extensions, at no extra charge. That means, you can do what I have done: clone inbound call handling behavior of four DIDs to three OBi devices, a wireless IP phone system, and even a simple ATA running a 1947 Western Electric 302 rotary dial phone.
Drgeoff and I do get bitchy some times, but we do have a lot of experience, and I don't shy away from telling a poster that they're wasting their time on a proposed solution.
Navigation
[0] Message Index
[#] Next page
[*] Previous page