I would like to setup a single stage dialing as
Sip client -> Asterisk -> Obi110 #1 -> Obi110 #2 -> pstn
Is it possible?
I am able to get Obi110 #2's AA with single stage dialing from Sip client.
Please help!
I can do sing stage dialing use a phone attached to Obi110 with speed dial.
ie. 1*123456789, 123456789 will dial out from pstn.
Can someone explain how the single dialing works internally, such as how's being processed by obi?
Am I be able to do single stage dialing without using speed dial through a phone?
Thanks in advance.
Single stage dialing involves a target OBi number, a number to be dialed from the target OBi, and a particular trunk to use on the target OBi. Originating the call from anything other than an OBi or OBiON app is problematic as there's no way to specify these three components and have them passed though Google Voice, a SIP provider, or the PSTN in a single stage process. Even OBi(ON) to OBi takes a limited approach of only supporting calling out the default (PrimaryLine) trunk (reducing the problem to two components).
The following is not from any documentation and is speculation on my as to what's happening internally.
The OBiTALK Service protocol supports passing a number to be called as data piggy-backed on the OBi(ON) to OBi call. When an incoming call arrives at the OBiTALK Service trunk, the CallerID of the originating OBi(ON) is available as well as the number to be called. These can be evaluated in the InboundCallRoute as:
{(CallerID)>(NumberToCall):terminal}
allowing single stage dialing to ensue. Calls arriving from Google Voice, SIP provider, or the PSTN have no way to convey a number to call, so two stage dialing is the only option.
The OBiTALK Service terminal appears to accept input in two formats:
1. ob200123456 : which initiates a simple OBi(ON) to OBi call with no number to call data.
2. <Speed Dial> * NumberToCall : which initiates an OBi(ON) to OBi call using the OBi number contained in <Speed Dial> with NumberToCall passed as data.
Quote from: freewilly on June 21, 2011, 12:06:37 PM
I would like to setup a single stage dialing as
Sip client -> Asterisk -> Obi110 #1 -> Obi110 #2 -> pstn
Is it possible?
I don't believe so. What can you dial at the Sip client that will be passed through Asterisk to OBi110 #1 such that OBi110 #1 can determine that you want OBi110 #2 called with a particular number to dial out the PSTN? The major hurdle is the Sip client -> Asterisk -> Obi110 #1 path.
Since Asterisk is involved could we not get direct dialing to OBi#2 using these instrcutions as per Ad_Hominem.
Quote from: Ad_Hominem on April 11, 2011, 02:42:36 PM
Revised: 4/11/2011
I've got the Obi 110 working with FreePBX and Google Voice. Using this set-up, I can dial calls from a PBX phone normally, and have them routed to either the Line Port or Google Voice. By default, these instructions will route ordinary calls (seven digit, ten digit, and eleven digit calls) to Google Voice and 911 calls to the line port. Optionally, users can dial 81 to force calls to the Line Port, or 85 to force calls to Google Voice. You can easily modify these instructions to meet your needs.
Possible to use OBi110 to as an FXO port on an Asterisk server?
http://www.obitalk.com/forum/index.php?topic=57.0
Thanks.
Currently I'm able to get
Sip client -> Asterisk -> Obi110 #1 -> Obi110 #2's AA
Quote from: RonR on June 21, 2011, 01:35:01 PM
2. <Speed Dial> * NumberToCall : which initiates an OBi(ON) to OBi call using the OBi number contained in <Speed Dial> with NumberToCall passed as data.
Is there a way to pass NumberToCall to Obi110 #2 without using this format <Speed Dial>*NumberToCall?
How can I get this work?
X_InboundCallRoute = {pp(<Speed Dial>*NumberToCall)}
PP(10*18005551212) will pass the number 18005551212 to the OBi whose OBiTALK number is stored in Speed Dial #10.
In an InboundCallRoute, it might look like:
Voice Services -> SP1 Service -> X_InboundCallRoute : {12341234567:pp(10*18005551212)}
This will route incomings calls on SP1 from 12341234567 to the OBi whose OBiTALK number is stored in Speed Dial #10 passing the number 18005551212.
Did exactly setup like this, Obi hangup on me right way.
And history of OB#1 never show it dial out P2P1 to OB#2
It works when I dial 10*18005551212 (where 10 is speed dial of OB#2, 18005551212 is the number dial out from primary line of OB#2) from the attached phone of OB#1.
Maybe <speed dial>*[phone number] works only on the attached phone.
Quote from: RonR on June 21, 2011, 08:48:01 PM
Voice Services -> SP1 Service -> X_InboundCallRoute : {12341234567:pp(10*18005551212)}
I tested both examples before posting and they work here. The calls were from an OBi110 to an OBi100. 18005551212 was connected through SP1 (Google Voice) on the OBi100. The calls were originated from the OBi110, using its attached phone [10*18005551212], a Speed Dial entry [PP(10*18005551212)], or an SP2 InboundCallRoute rule [{1?2341234567:pp(10*18005551212)}] that intercepted a call from my cell phone number and redirected it to 18005551212 on the OBi100.
On the target (receiving) OBi, you need an appropriate InboundCallRoute rule to process the call:
Voice Services -> OBiTALK Service -> InboundCallRoute : {(200123456)>(Msp1):sp1}
where 200123456 is the OBi #1 OBiTALK number.
RonR, you are right. It works with AA or attached phone.
I want dial out with single stage dialing through this path
SipClient(CSipSimple) -> Asterisk(1.8.4) PBX -> Obi#1's Sp2 -> Obi#1's ObiTalk -> Obi#2's ObiTalk -> Obi#2's PSTN
There is NO AA or attached phone involved.
How is this part lashed up? : SipClient(CSipSimple) -> Asterisk(1.8.4) PBX -> Obi#1's Sp2
Am I correct in assuming that SipClient(CSipSimple) is an extension (say 201) on Asterisk(1.8.4) PBX and Obi#1's Sp2 is another extension (say 202) defined on Asterisk(1.8.4) PBX as sip:anything@w.x.y.z:5061, where w.x.y.z is Obi#1's IP address?
Do you access Obi#1's Sp2 from SipClient(CSipSimple) by dialing 202?
That's right, I dial 202 to connect Obi#1's Sp2.
I would like dial 202*18005551212 at SipClient, then Obi#2's PSTN will dial out 18005551212 for me.
How do I send 18005551212 to Obi#2?
Let me state up front that I only know enough about Asterisk to be dangerous.
I think the real problem is as I described in Reply #1 above. The problem is not with the OBi. The problem is how do you get the desired number through SipClient(CSipSimple) -> Asterisk(1.8.4) PBX to the OBi. If you can get the desired number through to the OBi, the rest is easy.
The ideal situation would be to have anything you dial at SipClient(CSipSimple) (such as 18005551212 or **218005551212 or 10*18005551212) be received by Asterisk(1.8.4) PBX and sent directly to OBi #1 as DialedNumber@w.x.z.y:5061 using a SIP INVITE. Then you could have OBi #1 do anything you want with it by evaluating it in the SP2 InboundCallRoute. This could include sending it on to OBi #2 via OBiTALK. The processing in the OBi is easy. What I don't know is if it's possible to get Asterisk to pass the dialed number from SipClient(CSipSimple) to OBi #1 using a SIP INVITE. If you can accomplish this Asterisk task, the rest is trivial.
Is there a particular reason you've got Asterisk in the loop? If SipClient(CSipSimple) (or some other client) can make and receive SIP calls without registration, it should be able to talk to the OBi directly and I think all your problems go away. I have a PAP2 doing this and can handle almost any dialing sequence from the phone attached to the PAP2. I have it pretty much mimicking the phone attached to the OBi's PHONE Port.
I like CSipSimple because it simply can be integrated to Android phone dialer and uses bluetooth while Obion can't.
It is pretty simple pass string(your obi number and pstn dial out number) from asterisk to Obi110 #1's Sp2
exten => 3334,n,Dial(SIP/200123123*18005551212@1111,20)
where
3334 is the extension I dial out from CSipSimple,
1111 is the extension of Sip at Obi110 #1's Sp2
200123123 is Obi110 #2
18005551212 is the number I want dial out from pstn
I know Obi110 #1's Sp2 receive data send from asterisk, because it try to dial out from P2P1 200123123*18005551212 under call history session.
from CLI, I see
-- Called 200123123*18005551212@1111
-- SIP/1111-0000010a is ringing
-- Got SIP response 486 "Busy Here" back from 192.168.1.109:5061
-- SIP/1111-0000010a is busy
== Everyone is busy/congested at this time (1:1/0/0)
-- Executing [3334@normal-out:3] Hangup("SIP/1001-00000109", "") in new stack
== Spawn extension (normal-out, 3334, 3) exited non-zero on 'SIP/1001-00000109'
Maybe something in the DigitMap of ITSP Profile B need to be modified?
The ITSP Profile B DigitMap doesn't come into play, so it's not of interest.
The way I envision this working, you don't want or need anyone to know about OBi #2 other than OBi #1.
The crucial question is:
Can you make Asterisk deliver any number you dial on CSipSimple unchanged to OBi #1 via a SIP INVITE?
If so, all the work goes on in the OBI's. I already have it implemented and tested here and can provide it to you. You'll be able to call out any trunk on OBi #1 or OBi #2 (or OBi #3, #4, #5, ...) from CSipSimple without using the AA (i.e single stage dialing) using the same methods used on the telephone connected to the OBi PHONE Port:
18005551212 -> OBi #1 PrimaryLine
**118005551212 -> OBi #1 SP1 Service
**218005551212 -> OBi #1 SP2 Service
**818005551212 -> OBi #1 LINE Port
2*18005551212 -> OBi #2 PrimaryLine
2**118005551212 -> OBi #2 SP1 Service
2**218005551212 -> OBi #2 SP2 Service
2**818005551212 -> OBi #2 LINE Port
I can't get this work. I believe OBi device doesn't support it.
simple test,
Obi#1.sp2.X_InboundCallRoute: {(xx.):pp(2*18005551212)}
Call Obi#1.sp2 using cell phone or any phone NOT attached to Obi#1.
It tells Obi that any incoming call of Obi#1.sp2, route to 2*18005551212, which dial 18005551212 from Obi#2.PrimaryLine.
It just simply doesn't work. Obi#1 hangup on me right way.
With:
OBi #1 -> SP2 Service -> X_InboundCallRoute : {(xx.):pp(2*18005551212)}
and
OBi #2 -> OBiTALK Service -> InboundCallRoute : {(200123456)>(Msp1):sp1}
where 200123456 is OBi #1 OBiTALK number.
Calling OBi #1 SP2 (a VoIP provider number) from my cell phone causes 18005551212 to be dialed out SP1 of OBi #2.
Trust me, this works.
The crucial question is:
Can you make Asterisk deliver any number you dial on CSipSimple unchanged to OBi #1 via a SIP INVITE?
If not, then this may be a dead end. If so, the solution is easy.
I did exact setup, still not working.
OBi #1 -> SP2 Service -> X_InboundCallRoute : {(xx.):pp(2*18005551212)}
and
OBi #2 -> OBiTALK Service -> X_InboundCallRoute : {(200123456)>(Msp1):sp1}
OBi #1's SP2 is connected to GV, by calling the GV number from my cell, got ring until GV voice mail kicks in.
tested both OBi #1's SP2 and OBi #2's SP1 are setup properly.
See attached call history from both devices, OBi #2 has no call at all.
Is there any other settings in Obi device other than default?
And I assume you got to directory assistance?
The question I keep asking and never geting an answer to is?
Can you make Asterisk deliver exactly what you dial on CSipSimple to the OBi?
IOW, if you dial **117195676742 on CSipSimple, can you make Asterisk send that exact number unchanged (**117195676742) to OBi #1 SP2? If so, you can have single stage dialing to OBi #2 from CSipSimple.
The call to 18005551212 should have gone out SP1 of OBi #1. The test was not supposed to go to OBi #2. You kept saying the basic {(xx.):pp(2*18005551212)} syntax didn't work and I was just trying to show you it does.
Again, if you can dial any arbitrary number on CSipSimple and have it delivered unchanged via a SIP INVITE from Asterisk to OBi #1 SP2, one stage dialing out any trunk of OBi #1 OR OBi #2 is possible.
Earlier you wrote:
Quote from: freewilly on June 22, 2011, 10:45:37 PM
It is pretty simple pass string(your obi number and pstn dial out number) from asterisk to Obi110 #1's Sp2
exten => 3334,n,Dial(SIP/200123123*18005551212@1111,20)
where
3334 is the extension I dial out from CSipSimple,
1111 is the extension of Sip at Obi110 #1's Sp2
200123123 is Obi110 #2
18005551212 is the number I want dial out from pstn
I read this as OBi #1 SP2 being configured as a SIP extension on Asterisk.
But now you appear to have OBi #1 SP2 configured for Google Voice:
Quote from: freewilly on June 24, 2011, 02:14:47 PM
OBi #1's SP2 is connected to GV, by calling the GV number from my cell, got ring until GV voice mail kicks in.
If your asterisk system calls OBi #1 using a Google Voice number on SP2, there's no way I know of to do one stage calling from an extension on Asterisk for the reason stated back in Reply #1.
If you'd like to PM me an OBiTALK number I can reach you at, maybe we should talk about this.
Quote from: RonR on June 24, 2011, 02:23:32 PM
Can you make Asterisk deliver exactly what you dial on CSipSimple to the OBi?
RonR,
Yes, I'm able to do that.
asterisk extensions.conf
...
exten => _2*XXXXXXXXXXX,1,Answer()
exten => _2*XXXXXXXXXXX,n,Dial(SIP/${EXTEN}@1111,20)
exten => _2*XXXXXXXXXXX,n,Hangup
...
attachments are asterisk log, obi#1 and obi#2 settings.
I dialed 2*18005551212 from CSipSimple(ext 1001) on my cell phone.
Nothing in history on obi#2, call handup by obi#1(see asterisk log).
Make the following change in OBi #1:
Voice Services -> SP2 Service -> X_InboundCallRoute:
{exten>([1-9]x?*@@.):pp},{exten>(<**1:>(Msp1)):sp1},{exten>(<**2:>(Msp2)):sp2},
{exten>(<**8:>(Mli)):li},{exten>(<**9:>(Mpp)):pp},{exten>(Mpli):pli},{exten:},{ph}
Note: Replace pli above (2 places) with your PrimaryLine trunk name (sp1,sp2,li,pp,tg1) as the OBi won't.
Replace exten above (7 places) with the Peer Number shown on incoming calls to SP2 from Asterisk.
Make the following changes in both OBi #1 and OBi #2:
Voice Services -> OBiTALK Service -> InboundCallRoute:
{(Mcot)>(Mpli):pli},{(Mcot)>(<*1:>(Msp1)):sp1},{(Mcot)>(<*2:>(Msp2)):sp2},{(Mcot)>(<*8:>(Mli)):li},
{(Mcot)>(<*9:>(Mpp)):pp},{(Mcot)>(<**1:>(Msp1)):sp1},{(Mcot)>(<**2:>(Msp2)):sp2},
{(Mcot)>(<**8:>(Mli)):li},{(Mcot)>(<**9:>(Mpp)):pp},{(Mcot):aa},{ph}
Note: Replace pli above (2 places) with your PrimaryLine trunk name (sp1,sp2,li,pp,tg1) as the OBi won't.
User Settings -> User Defined Digit Maps -> User Defined Digit Mapx:
Label : cot
DigitMap : (200123456)
Note: These are trusted caller OBiTALK numbers.
In OBi #1, use OBi #2's OBiTALK number. In OBi #2, use OBi #1's OBiTALK number.
In the PHONE Port and Auto Attendant DigitMap's, replace [1-9]x?*(Mpli) with [1-9]x?*@@.
In the PHONE Port and Auto Attendant OutboundCallRoute's, replace {([1-9]x?*(Mpli)):pp} with {([1-9]x?*@@.):pp}
Set OBi #1 Speed Dial #2 to PP(ob200123456) where 200123456 is OBi #2's OBiTALK number.
From CSipSimple, you should be able to dial any number out any trunk of either OBi #1 or OBi #2:
18005551212 -> OBi #1 PrimaryLine
**1 18005551212 -> OBi #1 SP1 Service
**2 18005551212 -> OBi #1 SP2 Service
**8 18005551212 -> OBi #1 LINE Port
**9 200123456 -> OBi #1 OBiTALK Service
2*18005551212 -> OBi #2 PrimaryLine
2 **1 18005551212 -> OBi #2 SP1 Service
2 **2 18005551212 -> OBi #2 SP2 Service
2 **8 18005551212 -> OBi #2 LINE Port
2 **9 200123456 -> OBi #2 OBiTALK Service
Finally, it works.
I realize that my major mistake was speed dial #2,
it should be
PP(ob200123456) instead of
ob200123456Of course your X_InboundCallRoute setting make it much more secure than I had before.
Quote from: RonR on June 24, 2011, 06:19:15 PM
Set OBi #1 Speed Dial #2 to PP(ob200123456) where 200123456 is OBi #2's OBiTALK number.
Thank you so much.
You are the best.
freewilly,
This call routing approach also works for ATA's, SIP Phones, and OBiON apps without the need for Asterisk being involved. Simply load the OBiON app's gateway and Speed Dial slots with the appropriate OBiTALK numbers. This architecture is expandable to virtually any number of OBi's.
NOTE: Due to a bug in the OBi firmware, you cannot use *78 (Do Not Disturb) to silence incoming calls destined for the OBi's phone, nor can you use *72 (Call Forward All) to forward incoming calls destined for the OBi's phone. If either of these features is used, all InboundCallRoute processing stops on the SP1, SP2, and LINE Port trunks, breaking this call routing approach as well as any others utilizing these trunks. Even though correcting the problem is extremely simple, I've been informed by Obihai they will not be fixing this bug.
Quote from: RonR on June 25, 2011, 11:41:58 PMNOTE: Due to a bug in the OBi firmware, you cannot use *78 (Do Not Disturb) to silence incoming calls destined for the OBi's phone, nor can you use *72 (Call Forward All) to forward incoming calls destined for the OBi's phone. If either of these features is used, all InboundCallRoute processing stops on the SP1, SP2, and LINE Port trunks, breaking this call routing approach as well as any others utilizing these trunks. Even though correcting the problem is extremely simple, I've been informed by Obihai they will not be fixing this bug.
Did they happen to say why they won't be fixing it? That seems like a rather serious bug. I hope they will reconsider. There are too many companies out there that don't give a damn about fixing bugs in a timely manner, but up to this point Obihai hasn't been one of them, so I find this post rather disturbing.
This is a serious bug. Here's a couple of simple yet very practical examples:
If you set a rule to have calls from another phone (your cell phone, for example) sent to the Auto Attendant so you can make outgoing calls using one of the OBi's resources, using *78 (Do Not Disturb) to silence other incoming calls will cause the call from your cell phone to ring endlessly instead of going to the Auto Attendant. Using *72 (Call Forward All) to forward other incoming calls (to your cell phone, for example) will cause calls from your cell phone intended for the Auto Attendant to be forwarded right back to your cell phone instead. Certainly not what is expected or intended.
If you set a rule to block telemarketers or other unwanted callers, using *72 (Call Forward All) to forward other incoming calls (to your cell phone, for example) will cause all those telemarketers and other unwanted callers to be forwarded right to your cell phone. Certainly not what is expected or intended.
And, of course, more elaborate uses of the InboundCallRoutes such as the call routing capabilities described in this thread and others, using ATA's and SIP Phones with the OBi, etc., all fail completely if *72 or *78 are used.
The only work-around is to manually edit up to FOUR InboundCallRoutes every time you want to silence (and unsilence) the OBi phone or forward (and unforward) OBi phone calls without breaking everything else. Not very practical.
The problem in the OBi firmware is a simple one and very easy to fix. The order of checking to see if Do Not Disturb or Call Forward All is enabled and processing the InboundCallRoute is simply reversed. These operations are being performed in the correct order on the OBiTALK Service trunk (in order to allow OBiON- and OBi-to-OBi calls to work properly with *72 and *78), but are performed in the wrong (reversed) order on the SP1, SP2, and LINE Port trunks. The solution is terribly obvious.
I agree this is a VERY serious bug, and needs to be fixed. But you said that you've "been informed by Obihai they will not be fixing this bug." I can't imagine why they would take that position, which seems totally unreasonable on the face of it. How did they respond to you, via e-mail? Did they offer ANY explanation as to why they would not fix it?
This especially appears to have bad implications for those using an OBi110 as a gateway between a PSTN line and an Asterisk server, because if you're describing the situation accurately then setting the phone port to Do Not Disturb or Call Forward All would block incoming calls on the Line port from reaching the Asterisk server. That is most definitely unacceptable behavior.
This problem is easily reproduced. Simply set one or more rules on the SP1, SP2, or LINE Port InboundCallRoute(s) and then enable Do Not Disturb (*78) or Call Forward All (*72). You'll find those rules are ignored.
Clearly, features like DND and CFA should only be acted upon for calls actually arriving at the PHONE Port. That's the way the OBiTALK Service trunk behaves and all the other trunks should behave identically. There's no reason to treat SP1/SP2/LI differently.
Still no comment from Obihai Support???
Hi everyone,
Over the past several weeks, we have discussed and thought about the issue described in this post. We do see that the current implementation could be enhanced -- and of course it will be enhanced for various other applications. Understanding the DND & Call Fwd All limitation, the functionality in the current implementation should allow the OBi to perform well for this application. But as I said, we are considering this concern about the current implementation and are open to enhancing the current functionality.
Thank you for your support!
Sherman,
You continue to describe this problem as a need for some new functionality, capability, or enhancement. That's simply not the case. Absolutely nothing new is needed. Absolutely nothing needs to be enhanced.
The logic on the SP1, SP2, and LINE Port trunks is currently:
Do Not Disturb enabled? Yes -> Ignore Call / End of Processing
|
V
Call Forward All Enabled? Yes -> Forward Call / End of Processing
|
V
Process InboundCallRoute
|
V
Ring OBi Phone
If Do Not Disturb or Call Forward All is enabled, the InboundCallRoute doesn't get processed.
All that's needed to fix this problem is a trivial change to the order in which these operations are performed:
Process InboundCallRoute
|
V
Do Not Disturb enabled? Yes -> Ignore Call / End of Processing
|
V
Call Forward All Enabled? Yes -> Forward Call / End of Processing
|
V
Ring OBi Phone
The OBiTALK trunk performs these operations in the correct (second) order and consequently has no problem. Simply follow the same order on the SP1, SP2, and LINE Port trunks and the problem is solved. The change can't possibly take more than a few minutes to accomplish.
Why is there so much reluctance to correct this problem? Currently, numerous tasks that people are accomplishing with the OBi cease to function if Do Not Disturb or Call Forward All is enabled. Moving the placement of a single operation so that it matches the OBiTALK order allows all these tasks to continue working instead of being terminated. It's such an obviously devastating problem that's so simple to fix, it's hard to understand why we're even having this discussion.
Sherman, why didn't you answer this?