There is an option under the web portal that Obiapps can assign a OBi110 as voice gateway.
Speed dial + * + tel number allows me to dial out via the OBi110 device.
However, I notice that it is always go through SP1 i.e. my google voice account. Is it possible to allow me to go through PSTN or SP2?
For an app you can set an Obi as the default gateway so that you only have to dial the 10 digit number, not the speed dial designation. This is called single stage dialing.
the speed dial + * is for direct dialing from one Obi through another (but it can be used from the app also).
Single stage & direct dial always goes through the default line. If you want to use a different line all the time for your direct dialed calls you can set that in the Obitalk InboundCallRoute.
You will have to go through the AA if you want options on which line to use instead of the default.
Could you give me an example to change the inbound rule so that I can dial via SP2 or PSTN?
Once you set the Obi as the default gateway for your softphone app at the dashboard, your
Voice Service > Obitalk Service > InboundCallRoute should look similar to this
{(290xxxxxx)>(xx.):SP1},{(290xxxxxx):aa},{ph}
{(290xxxxxx)>(xx.):SP1} is the part of the rule directing single stage dialed calls from your app
SP1 represents the line for the outgoing call. change it to sp2 or li depending on which line you want the call to go out on.
Basically it says,
1 - calls coming in from 290xxxxxx along with 2 or more digits are routed as an outbound call through SP1
2 - calls coming in from 290xxxxxx with no other digits are directed to the AA
3 - calls coming in from other numbers are routed to the phone port
I haven't actually tried this, but you should be able to do some fairly fancy things with the OBiTALK Service InboundCallRoute. For example:
{(200123456|200654321)>(1xxxxxxxxxx):li},{(200123456|200654321)>(011xx.):sp2},{aa}
This should allow OBiTALK callers 200123456 and 200654321 to make direct calls, with US/Canada calls being directed to the LINE Port and international calls being directed to the SP2 Service. All others would be sent to the Auto Attendant, where they could make 2-stage calls, including calls to your OBi telephone by dialing 0 (use PIN protection to ensure only authorized users can make calls through the Auto Attendant).
RonR,
can we use some variations of the rule to place calls on a certain line determined by a prepended digit, like the international prefix.
If the Obi sees exactly what we send can't we add our own prefix to designate the line we want to use, and then have the Obi drop the prefix before dialing.
{(200123456|200654321)>(011xx.):sp2}
that tells the Obi to route all calls with 011xxxx to sp2. What needs to be added for the Obi to drop 011 from the number prior to dialing.
Since I know I won't be making any international calls I don't have to worry about conflicting digits.
I could use 002 for sp2 & 003 for line with the default being sp1.
I would think so, but I have very little experience with the OBiAPPS at the moment, so I don't know what, if any, limitations may have been built into them. Your best bet is to try whatever you have in mind and make sure it works.
I will play with it, but tell me what to use to make it drop the prefix before dialing. It is easier than searching, lol
Quote from: jimates on April 07, 2011, 06:34:47 PM{(200123456|200654321)>(011xx.):sp2}
that tells the Obi to route all calls with 011xxxx to sp2. What needs to be added for the Obi to drop 011 from the number prior to dialing.
Although I don't find any such examples, I would hope that normal DigitMap syntax applies:
{(200123456|200654321)>(
<011:>xx.):sp2}
Thanks for advice. I will try further to test out. I now understand that I need to look in detail in the configuration so as to allow dialing out.
Quote from: RonR on April 07, 2011, 06:47:34 PM
Although I don't find any such examples, I would hope that normal DigitMap syntax applies:
{(200123456|200654321)>(<011:>xx.):sp2}
I can replace the 011 with anything and it will direct the call to sp2 but it dials it as it is input, and of course google says it can't complete the call.
Since there is no outbound call route for Obitalk everything has to be in the rule for the incoming call.
If that's the case, obi-support2 is probably the only one who can tell us what the allowable syntax is and what its behavior will be. I would have thought it would be consistent throughout the OBi, but who knows? For example, ob200123456 is a valid OBi number in an OutboundCallRoute but the 'ob' part is invalid in an InboundCallRoute.
I understand.
can it be done at two points.
from where I am Obitalk will route the call to sp2, can we remove the prefix once it gets to the sp2 digit map or call route, or is it already past those items when Obitalk sends it to sp2.
maybe obitalk can send it to a digitmap per the prefix and then the digitmap can send it to sp2 where the prefix can be removed like other prefixes.
I remember, this is something that a couple of people have asked about doing.
The DigitMaps and OutboundCallRoutes you're referring to don't come into play anywhere in this scenaro that I'm aware of.
If the InboundCallRoute callee embedded-digit-map behaved like an OutboundCallRoute callee embedded-digit-map, I don't think there'd be a problem to solve.
Wonder if something worng with this
{>(1xxxxxxxxx):sp1},{>([2-9]xxxxxxx):li},{aa}
my SP1 is google voice
Landline works but if I have 1234234234, it will go to aa instead
I decided to try it the way it should work, and it does.
I dialed **2 xxx xxx xxxx and it rang to the AA.
I added your rule to the inbound call route and replaced the 001 prefix with **2 & **8
{(290xxxxxx)>(xx.):SP1},{(290xxxxxx)>(<**2:>xx.):sp2},{(290xxxxxx)>(<**8:>xx.):li},{(290xxxxxx):aa},{ph}
works just like it should. dialing without a prefix uses the default line.
when I dial using **8 it rings once, then there is a ~6 second delay (waiting for the line to connect I assume) then it rings again with a different ring (from the line provider I am sure).
I do remember others asking about a feature for this and Obihai said the AA would have to be used for anything other than the default line. maybe a fix they didn't tell us about yet.
Quote from: ckleea on April 07, 2011, 08:10:20 PM
Wonder if something worng with this
{>(1xxxxxxxxx):sp1},{>([2-9]xxxxxxx):li},{aa}
my SP1 is google voice
Landline works but if I have 1234234234, it will go to aa instead
You don't have the correct number of x's. It should be:
{>(1xxxxxxxxxx):sp1},{>([2-9]xxxxxx):li},{aa}
The bigger problem I see with this is that ANYONE can make direct calls out your SP1 and LINE ports.
Quote from: ckleea on April 07, 2011, 08:10:20 PM
Wonder if something worng with this
{>(1xxxxxxxxx):sp1},{>([2-9]xxxxxxx):li},{aa}
my SP1 is google voice
Landline works but if I have 1234234234, it will go to aa instead
this is the default call route with the addition of the new rules.
Obitalk Service > InboundCallRoute
{(290xxxxxx)>(xx.):SP1},{(290xxxxxx)>(<**2:>xx.):sp2},{(290xxxxxx)>(<**8:>xx.):li},{(290xxxxxx):aa},{ph}
dialing 10 digits uses the default - sp1
dialing **2 + 10 digits uses sp2
dialing **8 + 10 digits uses the line
I know RonR can shorten that up like it should be
Quote from: RonR on April 07, 2011, 08:22:02 PM
Quote from: ckleea on April 07, 2011, 08:10:20 PM
Wonder if something worng with this
{>(1xxxxxxxxx):sp1},{>([2-9]xxxxxxx):li},{aa}
my SP1 is google voice
Landline works but if I have 1234234234, it will go to aa instead
You don't have the correct number of x's. It should be:
{>(1xxxxxxxxxx):sp1},{>([2-9]xxxxxx):li},{aa}
The bigger problem I see with this is that ANYONE can make direct calls out your SP1 and LINE ports.
My line requires eight digits. It does work for line but not sp1
Can it be like this
{(290xxxxxx)>(1x.):SP1},,{(290xxxxxx)>([2-9]xx.):li},{(290xxxxxx):aa}
Quote from: jimates on April 07, 2011, 08:21:36 PM
I decided to try it the way it should work, and it does.
I dialed **2 xxx xxx xxxx and it rang to the AA.
I added your rule to the inbound call route and replaced the 001 prefix with **2 & **8
{(290xxxxxx)>(xx.):SP1},{(290xxxxxx)>(<**2:>xx.):sp2},{(290xxxxxx)>(<**8:>xx.):li},{(290xxxxxx):aa},{ph}
works just like it should. dialing without a prefix uses the default line.
when I dial using **8 it rings once, then there is a ~6 second delay (waiting for the line to connect I assume) then it rings again with a different ring (from the line provider I am sure).
I do remember others asking about a feature for this and Obihai said the AA would have to be used for anything other than the default line. maybe a fix they didn't tell us about yet.
Were you actually dialing [SpeedDial] * **2 xxx xxx xxxx or just **2 xxx xxx xxxx?
If the first case, it makes sense and the InboundCallRoute callee enbedded-digit-map is working like I thought it should, and maybe your initial testing with '011' removal was somehow flawed. If it's the second case, this does not compute unless there's been a major change to the OBiTALK calling procedure and internal handling.
Dialing without a prefix should have used SP1 (maybe that's your default line by coincidence).
I think the post you were referring to is this one:
http://www.obitalk.com/forum/index.php?topic=320.msg2901#msg2901
It may get the job done, but in my opinion, it's a little hinky. :)
It also confirms that InboundCallRoute callee enbedded-digit-map works the way one would expect it to.
no speed dial. I dialed from the app just as you would from the phone port. This wasn't possible in the past.
originally I put the rule [{290xxxxxx)>(<011:>xx.):sp2|] in
and changed 011 to 002 [{290xxxxxx)>(<002:>xx.):sp2|]
From the app I dialed 002 xxx xxx xxxx and the call went out on sp2 but the call history shows it was delivered exactly as 002xxxxxxxxxx so google rejected the call.
After looking at all the digit maps and call routes, I just decided to try it like it should have been all along.
Wait a minute, what you're doing (**2 xxx xxx xxxx) does make sense, just not in the spirit of what this thread is all about. This thread started as [SD] * number, but it's digressed in to a vanilla call to the OBiAPP's default gateway (with an enhanced InboundCallRoute). I think we've come the long way around to figuring out that InboundCallRoute callee enbedded-digit-maps do work the way one would expect except for your explicit digit cases. I think that's the only mystery at the moment, and I'm getting too tired to wrestle with it anymore tonight. :)
yes, it got a little off track when you noted the possibility of direct dialing from the app as if we were using the phone port. And I took that info and ran with it in a slightly different direction.
In the end my findings gave a fix to the OP's question of placing a call from the app, using a line other than the default.
Quote from: RonR on April 07, 2011, 09:04:41 PM
Quote from: jimates on April 07, 2011, 08:21:36 PM
I decided to try it the way it should work, and it does.
I dialed **2 xxx xxx xxxx and it rang to the AA.
I added your rule to the inbound call route and replaced the 001 prefix with **2 & **8
{(290xxxxxx)>(xx.):SP1},{(290xxxxxx)>(<**2:>xx.):sp2},{(290xxxxxx)>(<**8:>xx.):li},{(290xxxxxx):aa},{ph}
works just like it should. dialing without a prefix uses the default line.
when I dial using **8 it rings once, then there is a ~6 second delay (waiting for the line to connect I assume) then it rings again with a different ring (from the line provider I am sure).
I do remember others asking about a feature for this and Obihai said the AA would have to be used for anything other than the default line. maybe a fix they didn't tell us about yet.
Were you actually dialing [SpeedDial] * **2 xxx xxx xxxx or just **2 xxx xxx xxxx?
If the first case, it makes sense and the InboundCallRoute callee enbedded-digit-map is working like I thought it should, and maybe your initial testing with '011' removal was somehow flawed. If it's the second case, this does not compute unless there's been a major change to the OBiTALK calling procedure and internal handling.
Dialing without a prefix should have used SP1 (maybe that's your default line by coincidence).
I think the post you were referring to is this one:
http://www.obitalk.com/forum/index.php?topic=320.msg2901#msg2901
It may get the job done, but in my opinion, it's a little hinky. :)
It also confirms that InboundCallRoute callee enbedded-digit-map works the way one would expect it to.
Adter some trials, I got it work by changing to
{>(<*1:>xx.):sp1},{>(<*2:>xx.):sp2},{>(<*8:>xx.):li},{>(<*9:>xx.):pp},{aa}
Wonder if this is secure enough as I remove caller identity before proceed.
Quote from: ckleea on April 07, 2011, 10:46:12 PMWonder if this is secure enough as I remove caller identity before proceed.
I don't believe there is any security at all. I think anyone with your OBi number can make all the calls they want to using your SP1, SP2, and LINE services, all at your expense.
The Circle of Trust business works by allowing only authorized callers through your InboundCallRoute. You've opened it up to the whole world.
I have made some changes to make it more secure.
Thank for your advice.