Hello,
I'm the proud owner of a new Obi1022--and I love it! However, I have a few questions:
1. Before I added the Obi1022, I had only the Obi202 unit with two Vitelity accounts: SP1 that rang PH1 and SP2 that rang PH2. I used the system with a 2-line Panasonic cordless phone system using an RJ11 plug that goes into PH1 and splits to each of the two lines.
Now that I added the Obi1022, all incoming calls are ringing only on the Obi1022 unit and not to the Panasonic that's attached to the RJ11 port on the back of the Obi202... Do I really need to modify the InboundCallRoute so that it rings the Obi1022 and the Obi202??? If yes, then I don't understand why the Obi1022 rings and not the Obi202--because previously the Obi202 was ringing so somehow the Obi1022 device "took over" and became the device that rings preferentially over the Obi202... As of now, I have not manually tweaked the InboundCallRoute values for any device so it's a mystery to me as to how the Obi1022 is now ringing.
2. I don't really understand what would happen if the Obi202 lost power. Would my Obi1022 continue to function so that I can make outgoing calls and receive inbound calls? If the Obi202 needs to stay in the loop then what role is it playing in my phone system? It's confusing because when I pick up Line 1 on the Panasonic and make a call, I expected that I would hear the call already in progress on the Panasonic if I were to go to the Obi1022 and pick up the same Line 1 SP1 there... But I get a dial tone on the Obi1022. So it seems that each Obi device (202 and 1022) are independently connected to Vitelity. That's why it's unclear to me whether or not the Obi202 needs to remain in the loop at all times. It's even more confusing to me that each Obi device seems to have its own Auto Attendant (but that's a discussion for another day!).
Thank you,
Steve
How did you set up the 1022? Did you use the same two Vitelity SIP registrations on the 1022 as you did on the 202? That's not likely to work. I don't know if Vitelity offers sub-accounts or extensions, but you can call them and ask. The issue is that you're registering two different user agents (the 202 and the 1022 to the same SIP credentials at the same time, which is likely not permitted, so only the most recent UA to (re)register will work.
Oh, shows you how much I have to learn... I did exactly as you suspected so now it all makes sense. By the way, even if what I did isn't permitted, I was able to make two outbound calls on the same "line" (for example, I used SP1 on my phone (the 1022 device) to call my cell then I used SP1 on the Panasonic (the 202 device) to call my cell and both calls were serviced as if I had an extra outbound line).
Perhaps I should explain what I wanted to do:
1. I wanted to keep the Obi202 operating as it was and simply add the Obi1022 as a desk phone. I want the Obi202 to be attached to my two separate Vitelity DID accounts as before and (ideally) I'd want to be able to receive and make calls from the phone attached to the Obi202 and from the Obi1022 phone. Is this possible?
2. Ideally, I want to be able to pack my Obi1022 and take it with me to a vacation home so that I can make/receive calls from that home. I bought the Obi1022 rather than travel with my Obi202 because I did not want to disconnect my then one-and-only Obi202 device during what would be a day of domestic travel during the week...
Thank you,
Steve
Normally, you would setup 2 extensions at the service provider, one for each OBi device. Then you would need to setup routing at the provider to send inbound calls to both extensions. This is the preferred method. I don't know if Vitelity has this feature.
The OBi can also solve your problem. Just send inbound calls to the other device using the OBiTalk network. I assume either the 1st or last device to register to Vitelity will receive inbound calls. Since you can't guaranty with device will register last, send the call both devices to the other.
Use OBi Expert to make the following change.
Voice Services -> SPx Service -> X_InboundCallRoute: ph,pp(510123456)
Change 510123456 to the OBi Number of the other device.
You would make this change for both Vitelity accounts on the OBi202 and the OBi1022. That's 4 inbound routes.
Also on both devices:
Voice Services -> OBiTalk Service -> InboundCallRoute: ph
This is the default setting, but when you add your devices to OBiTalk code is added to send calls to the Auto Attendant. You should remove this code.
OK, I think I understand the outbound routing instructions--I'm not yet sure I understand the inbound routing, but I'll give it a go and I'll write again here if I have any follow up questions...
Thanks!
Steve
Quote from: eightminobi on June 24, 2016, 07:19:09 PM
OK, I think I understand the outbound routing instructions
What outbound route?
You are modifying the inbound routes for the Vitelity SP services and the inbound route for the OBiTalk service.
Voice Services -> SPx Service -> X_InboundCallRoute: ph,pp(510123456)
ph will send the call to the local phone port.
pp is specifying the OBiTalk Service, so pp(510123456) is also sending the call to the device with OBi number 510123456 using the OBiTalk network.
Voice Services -> OBiTalk Service -> InboundCallRoute: ph
The remote device will receive the call via the OBiTalk service.
ph will send the call to the remote device's phone port.
The first device to answer will be connected.
I posted a new message because it occurred to me that I have no clue what ObiTalk is and why it's necessary.
Thank you,
Steve
If you don't need the OBi202 when you travel, you should be able to make this work without adding your devices to OBiTalk by powering off the OBi202 before you leave. You can test this by pulling the plug on both devices, wait a minute then power on the OBi1022. Now the OBi1022 should receive inbound calls.
Vitelity does support sub-accounts.
See: Extra Devices and Sub Accounts
http://www.vitelity.com/faqs/
Setup a sub-account on Vitelity.
You would keep the OBi202 registered to the main account.
Change the OBi1022 to register to the sub-account.
I don't know if call routing is automatic or you have to setup a route for the sub-account.
This would be better than having the OBi202 route the call.
The call path would be from Vitelity to the OBi202 then from the OBi202 to the OBi1022 over the OBiTalk network.
With a sub-account the call will go from Vitelity directly to the OBi1022.
Now you won't have to screw around with OBiTalk.
Hi,
Vitelity does support sub accounts. I created a new one and changed the registration of the OBi1022 to it. Then I used Vitelity's route feature to route calls from my DID to the original sub account as well as to the new sub account.
Still, only the original sub account rang (i.e., the phone attached to the OBi202). When I removed the original account as a route, the OBi1022 rang...
It seems that Vitelity doesn't route to two sub-accounts simultaneously--it seems that it "hunts" between the two (and two is the maximum number of sub-accounts you can define--at least at my Vitelity subscription level).
The new sub-account is working for out-bound calls on the OBi1022, so I kept the sub-account. Now I can make outbound calls from either my Panasonic (attached to the OBi202) or from the OBi1022 phone.
To try to get both phones to ring simultaneously, I again went to the inbound route setting for SP2 on the OBi202 expert configuration page. I used your example:
ph,pp(510123456)
and changed the 9 digit number to the OBi number for my new OBi1022 phone. Still, only the Panasonic rang. When I remove ph, then I get to an auto attendant...
I don't really understand how pp(<obi number>) works. I get that it copies an inbound call and directs it to that OBi device, but since my device is a 1022 phone, I want the call to come in on Line 2, which corresponds to SP2 (the SP# I am configuring to ring on both devices).
Do you know why I'm getting connected to the AA?
How can I make Line 2 ring when using the pp(123456789) syntax???
Thank you,
Steve
Quote from: eightminobi on June 25, 2016, 11:30:16 PM
Hi,
Vitelity does support sub accounts. I created a new one and changed the registration of the OBi1022 to it. Then I used Vitelity's route feature to route calls from my DID to the original sub account as well as to the new sub account.
Still, only the original sub account rang (i.e., the phone attached to the OBi202). When I removed the original account as a route, the OBi1022 rang...
It seems that Vitelity doesn't route to two sub-accounts simultaneously--it seems that it "hunts" between the two (and two is the maximum number of sub-accounts you can define--at least at my Vitelity subscription level).
The new sub-account is working for out-bound calls on the OBi1022, so I kept the sub-account. Now I can make outbound calls from either my Panasonic (attached to the OBi202) or from the OBi1022 phone.
To try to get both phones to ring simultaneously, I again went to the inbound route setting for SP2 on the OBi202 expert configuration page. I used your example:
ph,pp(510123456)
and changed the 9 digit number to the OBi number for my new OBi1022 phone. Still, only the Panasonic rang. When I remove ph, then I get to an auto attendant...
I don't really understand how pp(<obi number>) works. I get that it copies an inbound call and directs it to that OBi device, but since my device is a 1022 phone, I want the call to come in on Line 2, which corresponds to SP2 (the SP# I am configuring to ring on both devices).
Do you know why I'm getting connected to the AA?
How can I make Line 2 ring when using the pp(123456789) syntax???
Thank you,
Steve
This sounds fishy.
Given that they support sub accounts, the main purpose of doing so is to allow multiple, distinct SIP registrations, with, in your case, two different SIP user agents (the 202 and the 1022). It is expected that outbound calls would work from both devices; the key issue is that having distinct SIP registrations will allow you to have two different inbound call paths. It's possible that you need to change the SIP port used by the second user agent. It's also possible that the customizations you made have broken this functionality.
Why don't you contact them for assistance? I can tell you that this works perfectly with my ITSP, Callcentric. It should work equally well with Vitelity.
Quote from: eightminobi on June 25, 2016, 11:30:16 PM
I don't really understand how pp(<obi number>) works. I get that it copies an inbound call and directs it to that OBi device, but since my device is a 1022 phone, I want the call to come in on Line 2, which corresponds to SP2 (the SP# I am configuring to ring on both devices).
Do you know why I'm getting connected to the AA?
How can I make Line 2 ring when using the pp(123456789) syntax???
1. The Obitalk network is a 'Line' in its own right, on a par with the other SPs. So a call forwarded to ob123456789 will not come in to OBi device 123456789 on SPx (SP1 to 6 on 1 1022.)
2. The OBitalk 'Line' has its own InboundCallRoute. Check (on the 1022) that is set to ph. It may have been changed to aa.
@drgeoff: Thanks, but I don't understand the bolded text...
So a call forwarded to ob123456789 will not come in to OBi device 123456789 on SPx (SP1 to 6 on 1 1022.)
I just would like to know how I direct an incoming call to the OBi1022 device's Line 2. If I only can direct to device ph on the 1022 or to the aa on the 1022, then fine--I suppose the call just comes in on the first available slot (by "slot", I mean the 5 phone-line entries on the right side of the display)... Ideally, I wanted calls from SP1 to route to Slot 1, calls from SP2 to route to Slot 2, etc. But then I'm not sure what I would want to happen if I am already using Slot 1 for another inbound or outbound call. Again, I am thinking of AT&T land-line behavior, in which case the caller would receive a busy signal (i.e., I'm on the line), I would get a call-waiting tone, or they would route to a "line-in-use" voice-mail message--or the incoming could hunt to the next available slot... Gee, this stuff gets complicated quickly...!
Unfortunately, there is no "bang head on table" emoticon in this forum editor.
I am willing to bet that this is a case of an engineer trying to "engineer" a solution that doesn't need to be "engineered". There is no need to do any digit map or call route changes, and, in fact, you have probably changed something that is now conflicting with using two different SIP registrations (sub accounts).
Just do this; it will take far less time than you have already spent.
1: Contact Vitelity and confirm with them that they support concurrent use of multiple sub accounts, and that both sub accounts will independently ring on inbound calls (that's the whole point of having them). If this isn't the case, then Vitelity sucks, and you can take your business to a better ITSP, like voip.ms or Callcentric.
2: Log into the OBiTALK web portal. Delete both of your devices off of the portal. Gone. Bye-bye.
3: Factory reset both devices, by dialing ***8, then 1 to confirm. Wait plenty of time for each device to fully reset and reboot.
4: You must get two separate extensions (aka sub-accounts) for each of your two DID numbers. Add both devices back to the portal, using the **5 procedure. Use the portal, not the local web interface, to configure your two Vitelity DID sub accounts per device (On the OBi 202, DID #1 extension 1, on SP1, and DID #2, extension 1, on SP2; on the OBi 1022, DID #1, extension 2 on SP1, and DID #2, extension 2, on SP2). To do this, click each SP, accept the warning about 911, scroll down to the bottom of the page, click "OBiTALK Compatible Service Providers", and then, on the next page, click "Vitelity".
5: You're done. It should simply work. If it doesn't work, change ITSPs.
There has been no over-engineering: Sometimes things that *should* work, don't. That doesn't mean that the person is over-engineering a solution or making things more complicated. I will contact Vitelity tomorrow. It is of course entirely possible that their "sub accounts" don't work the way they do for other ITSP (although that would be rather strange)--but it also might be a limitation based on my subscription level, etc. If they can't do it then I can switch ITSPs.
But until I ask questions here, I can't know whether I'm doing something wrong or not. For the record, I did in fact save the configurations for the OBi202 and 1022 before resetting them and trying again--still no luck. So all fingers seem to be pointing to Vitelity at this point.
Thank you,
Steve
The word from Vitelity is that you can use sub accounts to route to as many as two devices--beyond that you need a PBX, they said. They said they would help troubleshoot why dual routing is not working on my system.
But this still doesn't help answer the question as to why I can't continue to use single routing from Vitelity and let the OBi202 ring my OBi1022 whenever the OBi202 receives a call...
I'll do another reset on my two OBi units, I'll remove then re-add them to OBiTalk, then I'll reconfigure them. If using the inboundcallroute on the OBi202 doesn't help me to ring both the OBi202 phone and the OBi1022 phone at the same time then I'll re-post here. I don't really think a reset should be necessary (I'd rather troubleshoot the current configuration), but I understand it's probably faster to just reset everything...
Thanks,
Steve
Did you look at the setting of InboundCallRoute for Obitalk?
Yes, on the OBi202 it was ph,pp(510123456) (where the OBi number was the correct number for my OBi1022 phone and ph was for the OBi202 device).
Quote from: eightminobi on June 28, 2016, 01:00:43 PM
Yes, on the OBi202 it was ph,pp(510123456) (where the OBi number was the correct number for my OBi1022 phone and ph was for the OBi202 device).
That is not what I asked.
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..
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). Now let's talk about the devices...
2. At Vitelity, I currently have one route defined in my Vitelity account, and that route directs calls arriving on my DID to SubAccount01 (I have two DIDs, but let's just stick to one for now because if I solve the inbound-ring issue for one I can solve it for the other). Once that SubAccount01 was set up, I subscribed my OBi202's SP2 account to that Vitelity SubAccount01. At first, I kept the InboundCallRoute for the OBi202 on the device to simply "ph"... When I placed a test call to my DID, it got routed to the OBi202 ATA box and that device's InboundCallRoute (equal to "ph") caused the phone attached to the first RJ11 phone jack to ring. Fine.
After that succeeded, I registered the new OBi1022 device on my OBiTalk account. It appears on OBiTalk along with my OBi202 device.
Because my DID routes to Vitelity SubAccount01 and because my OBi202 SP2 subscribes and authenticates to that Vitelity SubAccount01, wouldn't it be true that all I need to do to get the OBi1022 to ring is to change the InboundCallRoute of the OBi202 from "ph" to "ph,pp(123456789)"--where 123456789 is the OBi ID of my OBi1022 device? If that device is registered on the ObiTalk network, wouldn't this configuration be sufficient to get my OBi1022 desktop phone to ring??? If no, why?
Thank you,
Steve
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.
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.
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.
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.
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.
First, although it's been four days, in truth I am tackling the install that's located in my office and not at home and I don't get to spend any time on it while home and only very limited time while at the office. Four days translated into maybe an hour of actual time--and most of that hour was spent reading posts here and posting my questions. Clearly, I wasn't toiling away incessantly for four sleepless days...
Second, there is a difference between someone who is trolling and trying to rile you guys and someone who is legitimately trying to understand new terminology and is using this forum as the support group it purports to be. Intended or not, I have the impression that this is a hostile-to-newbies group--and that's okay, but it's just not very inviting. I never have been shy admitting when I don't understand something and were it not for my own academic and professional achievements, this group would have me wondering whether or not I'm some sort of a dolt. I could understand if you had a "read this before posting" section so that you could come down hard on people who might not understand some basic facts about OBi devices or OBiTalk service, but as far as I know, that document doesn't exist. I understand that I'm quite new to VOIP and have almost no knowledge of the OBi products, and what I'm seeing on this forum from some posters is just a little bit of arrogance. I don't fault arrogance from people who've earned their stripes but it's just not my personality to engage them for too long, especially when things turn to ad hominem attacks, which I believe is tantamount to high-school bullying.
Now to wrap up: Everything I wanted to achieve is now working, so I'm happy! However, I realize that I have three VOIP points-of-failure: Vitelity, the OBiTalk network, and my OBi202--plus infrastructure failure points (power, for example) to boot. So when I combine those facts with your last message, I understand that I would be in a far better up-time situation to off-load as much of my phone system to a hosted ITSP/VOIP solution. I never needed to compare Vitelity to Callcentric, but it looks like it might be time to switch (I have no particular reason for staying with Vitelity...).
Thanks again for all your help,
Steve