Hello
first of all apologies if this topic was discussed before. I do recall seeing some
comments on a similar thread but can't locate any relevant topics anymore.
Suppose the following scenario:
lets say I'm in Europe, with a European mobile # having only voice service
(not data, no voip). I'd like to be able to initiate low cost calls from that mobile by being able
to reach the Obi auto-attendant back home (based in US), and
then have the auto attendant capture the mobile # *without answering*
the call, and immediately proceeding to call back the european mobile # using the SP1 or SP2 service
so that when I answer the call on the mobile I will be connected to the AA.
I'm thinking that the first step would be to have Obi route an incoming call from the mobile with
European number to the AA applying a inbound routing rule like the following to the appropriate interface:
{(12345678912):AA},{ph}
How do I configure the AA (if I do need to do something extra) to return a call to the originating #
(12345678912 in this case) but without answering the call in first place?
thanks
L.
indeed there was is a popular thread already on this which addresses this question.
Sorry for the redundant post.
http://www.obitalk.com/forum/index.php?topic=66.0
Assuming you're calling your OBi on the SP1 Service:
Voice Service -> SP1 Service -> X_InboundCallRoute : {12341234567:aa($1)},...
Upon receiving a call on SP1 from 12341234567 that is aborted before the Auto Attendant answers, the Auto Attendant will call back to 12341234567 using the Auto Attendant PrimaryLine.
You can have the Auto Attendant use a different trunk for the callback by altering the incoming number:
Voice Service -> SP1 Service -> X_InboundCallRoute : {(<**2>12341234567):aa($1)},...
In this case, the Auto Attendant would call back to 12341234567 using SP2.
Also see this post:
http://www.obitalk.com/forum/index.php?topic=2102.msg13284#msg13284
In the event the caller id captured is not the complete (or dial-able) phone # (ie the country code
was stripped), what would be the proper syntax to re-construct a proper call back #?
Assume the country code is "nn", and also assume that these 2 digits are the only digits that were stripped.
Then if I want to be able to dial back the international mobile # that initiated the call, will
the following modification suffice?
{(<**2nn>12341234567):aa($1)}
where "nn" is the country code?
thanks
Quote from: lk96 on January 09, 2012, 12:30:24 PM
{(<**2nn>12341234567):aa($1)}
That should cause the Auto Attendant to dial nn12341234567 using SP2.
I believe you could also do it as:
{12341234567:aa(**2nn12341234567)}
As long as the incoming CallerID is 12341234567, the Auto Attendant would dial nn12341234567 using SP2.
thanks.
I like replacing the $1 variable with the fully expanded and unambiguous phone # to be dialed
when the left hand rule is matched.
L.
Quote from: lk96 on January 09, 2012, 12:55:35 PM
I like replacing the $1 variable with the fully expanded and unambiguous phone # to be dialed
when the left hand rule is matched.
In this case, so do I.
The $1 variable can be quite useful, however, in cases where you have multiple or wild-card matches, such as:
{(12341111111|12342222222|12343333333):aa($1)}
or
{(12341234xxx):aa($1)
one follow up question:
suppose I want the AA to call back through 2 accounts/interfaces simultaneously (ie through both SP1 and SP2).
Does the Obi config allow such a possibility ?
The use case here would be as follows: in my case I tend to use really cheapo
providers when I'm in the US because I have plenty of options and choices
and ways to recover when some provider is out.
When I'm in Europe with a mobile in my hand, it will be critical to
get the call back. By forking the outbound calling from Obi through two providers,
the chances that at least one of the two providers is operational is much better.
I'm thinking that instead of using the variable $1 or the exact phone number in the AA( ... ) parameter,
a trunk group could be used instead? in this case the trunk group would consiste of the
2 cheapo SIP providers. If so, what does a TG syntax/config looks like ?
thanks
L.
I don't believe that you can fork two AA instances. However, the AA could call back into the OBi via the loopback address, e.g. 55555@127.0.0.1:5061. Then, the inbound route for SP2 could detect the 55555 and fork via two VGx. However, I suspect that you'll have problems with that approach. For example, a call with no or one-way audio arrives first, preventing the "good" path from getting through.
IMO, you should simply have two (or more) ways to trigger a callback, which would then use different providers. Possibilities include what number you call, e.g. your GV or IPKall DID, or what caller ID is sent, e.g. calling direct or via Rebtel. You might make use of free DIDs from UKDDI, ippi.fr or messagenet.it, or set up Localphone so calling a local number rings to your iNum (with any provider).
Quote from: lk96 on January 13, 2012, 11:34:00 AM
suppose I want the AA to call back through 2 accounts/interfaces simultaneously (ie through both SP1 and SP2).
Does the Obi config allow such a possibility ?
No. There is only one instance of the Auto Attendant and it can only initiate a single callback.
Quote from: lk96 on January 13, 2012, 11:34:00 AM
When I'm in Europe with a mobile in my hand, it will be critical to
get the call back. By forking the outbound calling from Obi through two providers,
the chances that at least one of the two providers is operational is much better.
The OBi does not support forking outbound calls.
Quote from: lk96 on January 13, 2012, 11:34:00 AM
I'm thinking that instead of using the variable $1 or the exact phone number in the AA( ... ) parameter,
a trunk group could be used instead? in this case the trunk group would consiste of the
2 cheapo SIP providers. If so, what does a TG syntax/config looks like ?
A Trunk Group doesn't guarantee that a call goes through. It simply allows specifying multiple trunks to be used in case the resources of one or more trunks are not available. You can set the Auto Attendant PrimaryLine to Trunk Group 1 and then define multiple trunks at Trunk Group1 -> TrunkList.
thanks for the responses on the trunk group. Will experiment shortly.
However, I just tried a basic experiment to see if I will get a call back and
the Obi doesn't seem to call back. Below is the inbound call route config:
{kkkkkkkkk|mmmmmmmmm):aa},{(nnnnnnnnnnnn):aa(xxxxxxxxxx)},{ph}
where:
kkkkkkkkk is an Obi #
mmmmmmmmm is another Obi #
nnnnnnnnnn: is the 12 digit incoming international phone exactly as captured in the Obi call history
xxxxxxxxxx: is a US based GV # (I didn't want obi to call back a european # that is in roaming). This
# should have been dialed over the primary line (LINE in this case). I also did an experiment
to send that call over SP1 (by prefacing the number with **1).
Do I miss something ?
L.
Quote from: lk96 on January 13, 2012, 01:06:46 PM
{(nnnnnnnnnnnn):aa(xxxxxxxxxx)}
The parenthesis around nnnnnnnnnnnn isn't needed (they do no harm).
A call from nnnnnnnnnnnn which is aborted before the Auto Attendant answers should cause the Auto Attendant to initiate a callback to xxxxxxxxxx using the
Auto Attendant PrimaryLine. This is assuming that the
Auto Attendant DigitMap and OutboundCallRoute match the xxxxxxxxxx number.
You can test the nnnnnnnnnnnn CallerID match by not hanging up and seeing if the Auto Attendant answers.
You can test the Auto Attendant's ability to call xxxxxxxxxx by dialing **0, pressing 2, then entering xxxxxxxxxx#.
I figured out why I was not getting the callback: even the 10sec interval was too short.
In fact (and unfortunately) the AA was picking the real call (it will be
a really expensive one). So once I increased this
and kept track of the time I was on the phone while getting the ring back
I did get the call back.
However, it seems that I hit some issue related to the use of trunk groups for the call back:
so I used a syntax like aa(tg1(1nnnnnnnnnn)) to tell the AA to use TG1 to callback the indicated number.
In the configuration of TG1 i replaced the default sp1, sp2 with li1 in order to force
the call out of LINE interface (just as an experiment).
The net result is that I did get the call back but not through the
LINE interface. When I went in the call history, the call was shown that went out through
TG1(1nnnnnnnnnn). But this does not tell me which actual interface was used.
Based on my Obi config I'm fairly certain though that the call went out through SP1
(because the above destination number would not be dialable through SP2 and have
validated that manually).
May be I'm pushing my luck here but ...any ideas ?
Is it possible that you can't have the AA use a TG to call back ?
sorry but this was a false alarm. The history did show the call used LINE1 interface.
And when I picked up the *correct" handset to "eavesdrop" on the returned call, I confirmed
that thing worked out fine.
So this is good news that using a TG in the AA callback definition worked as expected.
L.
What services do you have set up on your OBi? Which country SIM(s) do you have? In which countries will you be traveling?
I'm asking this, because there are probably ways to set up the OBi to have two or more callback choices, using local numbers dialed from the EU mobile. I live part time in France and use a prepaid phone there. My OBi is set up so I can dial one Paris number and get a callback via Voxbeam, or dial a different Paris number and get a callback via Orange.
There are also commercial callback services (more expensive than using the OBi, but still fairly reasonable) that can serve as a backup. Take a look at Fonworld and Future-Nine.
Quote from: Stewart on January 13, 2012, 06:51:32 PM
What services do you have set up on your OBi? Which country SIM(s) do you have? In which countries will you be traveling?
I have two Obis (100 and 110) currently located in the US. I have GV setup
on the 100 where SP1 is the GV service and SP2 is occupied to forward GV calls to a Grandstream IP phone.
The 2n Obi which is an 110 is in front of a Vonage adapter (which is my default family line). I have setup
easyvoip and voipalot on the SP1 and Sp2 services of the 110 respectively.
In the next few months I will install also one in Greece which I intent to use also for some
local mobile-to-mobile calls (through callback) so that calls are not backhauled back to my USA obi.
My calling needs are mostly in Greece and India at this stage (yes I know that India is not Europe.. was trying to keep the example cases limited).
In Greece I do have a SIM that I renew on each travel (so effectively I maintain the same phone #).
In India I get a new SIM every time I land there. Also occassionally I need similar service in
France and UK.
Quote from: Stewart on January 13, 2012, 06:51:32 PM
I'm asking this, because there are probably ways to set up the OBi to have two or more callback choices, using local numbers dialed from the EU mobile. I live part time in France and use a prepaid phone there. My OBi is set up so I can dial one Paris number and get a callback via Voxbeam, or dial a different Paris number and get a callback via Orange.
Can you please elaborate on this? I don't see how the Obi is in the call path.
Also: after seeing some of your posts I checked a bit Voxbeam. Do they offer their service
retail to individuals? or they mostly do wholesaling to companies/businesses. They do
have fairly aggressive pricing and if the do offer service to individuals I'm willing
to setup an account with them as well.
Quote from: Stewart on January 13, 2012, 06:51:32 PM
There are also commercial callback services (more expensive than using the OBi, but still fairly reasonable) that can serve as a backup. Take a look at Fonworld and Future-Nine.
Thanks. Will do.
L.
@lk96
You may want to look at LocalPhone.com (a Voxbeam company) as rates are pretty good also. They will give you a UK# for free.
Quote from: lk96 on January 14, 2012, 07:58:11 AMCan you please elaborate on this? I don't see how the Obi is in the call path.
I live part time in Paris and have an OBi there. It's configured with an Orange pseudo-POTS line (like your Vonage) on the LINE port, PBXes (sub-PBX) on SP1, Phonepower on SP2 and Voxbeam on VG1. For example, my prepaid mobile in France is 0612345678.
InboundCallRoute for the LINE port is: {(xx.612345678):aa(**80612345678)}, ...
So when I call the Orange number from my mobile, I hang up before the AA answers and it calls me back, using the LINE port, i.e. Orange.
InboundCallRoute for SP1 is: {(<**30011101>(33612345678)):aa($1)}, ...
I have a PBXes trunk registered to ippi.fr, with a free Paris number. When I call the ippi number from my mobile, I hang up before the AA answers and it calls me back, using Voxbeam and adding the Premium prefix.
Once I answer the callback, I can dial 2, then call out through any of the configured services.
Although my setup uses local numbers, you could use any DIDs anywhere in the world, as long as your mobile carrier doesn't charge you for an unanswered international call (and if that's a problem, see below workaround using Localphone). For example, you could route a free IPKall DID to your OBi110 SP1 and another to SP2. Calling one DID might trigger an Easyvoip callback and the other a Voipalot callback.
Both Easyvoip and Voipalot will accept unregistered (but authenticated) calls, so you can put them on a VGx and use the SPx for something else, e.g. Callcentric or Localphone, who provide free iNum DIDs. Then, you can set up a Localphone or Rebtel account to ring the iNum when you call an access number in your current country. Calls through Rebtel modify the caller ID; you can set the OBi to recognize the modified number and take a different action.
Voxbeam is the Costco or Sam's Club of wholesale VoIP, with lots of small customers. You get a $1 credit at startup, which is enough for lots of testing. Then, the minimum payment is $50, which expires after one year, implying minimum usage of $4+ per month. There is a 2.5% surcharge for credit card or Paypal payments, but you can pay by ACH to avoid that, if you have electronic bill payment with your bank, broker, credit union, etc. Also, they authenticate by IP only; if yours changes frequently, I can post a script that updates the site automatically. You might also look at FlowRoute, with slightly higher rates but fewer gotchas.
@lhm: thanks. Will keep that in mind.
@Stewart: thank for the detailed description. I got the idea.
What I didn't pay much attention to (even though I did come across
some posting) that were mentioning that some of the SIP services don't need
registration). This is actually very powerfull as I thought I couldn't use
my Obi100 (which had both ports occupied) to return my call back.
With that said, I'll take a look to see how I define such VG.
L.
after some more thinking on Stewart's response and advice, I'm trying to figure out the following:
Consider my case where both SP1 and SP2 of my Obi100 are used/occupied for GV and bridging GV calls
to an IP phone. As per Stewart's response, I can configure a VG to be the one
to be used by the AA to call me back through a SIP service that doesn't require
registration. So far so good.
Once I get the call back at the mobile phone, I will be on the Obi AA prompt. At that point
I will have to dial the destination number I desire to reach. How can I instruct the Obi
to use a VG or a trunk *other* than the SP1 and SP2 to dial out the destination number ?
I thought as a workaround that I could pre-program some speed dials.
But upon checking the admin guide it seems
that a speed dial cannot be a VG (only SP1, SP2, LINE and PP are allowed).
Any ideas how this can work ?
thanks
L
Quote from: lk96 on January 14, 2012, 07:59:11 PM
How can I instruct the Obi to use a VG or a trunk *other* than the SP1 and SP2 to dial out the destination number ?
Using OBi Voice Gateways with SIP Providers (http://www.obitalk.com/forum/index.php?topic=526.0)
I'm absolutely positively shocked/impressed with both the quality of the responses
and the flexibility/power of the device.
thanks much !
L.
So thanks to RonR and Stewart's suggestions I have a well setup configuration
where callbacks are configured to also use VGs. Additionally I have freed up an SP trunk
after the clarification that a lot of voip providers don't require SIP registration.
I have also obtained a free incoming DID from ipkall (I didn't realize that I could
forward an ipkall-obtained DID to my obi without going through another voip provider - thanks RonR
for a posting demonstrating that) (Note: when I dial the DID I got from ipkall from my cell phone
i get a ringback tone and the obi calls back as expected. However when I call the DID ipkall #
from my office phone (corporate phone but with a direct #) I get a busy tone and the Obi also
doesn't show any record of incoming calls. Not sure why this is so).
My next step is to look into Voxbeam. Voxbeam requires a real IP address (not DNS name)
to be used.
Stewart: you mentioned something about a script to do that automatically. Can you please share?
What kind of platform it runs on?
I really don't know how often my public IP address changes. For sure it changes when there
are service/device failures/reboots. I believe that in my case the address doesn't change otherwise.
But Mr. Murphy is sure to hit when I'll be traveling and when I need this to work urgently.
thanks
L.
I posted the Voxbeam update script at http://www.dslreports.com/forum/r26795392-script-for-Voxbeam-on-dynamic-IP-address . You may need to register to download the attachment.
I got another IPKall account and PMed you the number. It points to 883510000000093@sip.inum.net (caller ID test).
Stewart: I downloaded and will install on a new Mac server I'm setting up. Thanks much.
I do have couple of issues and questions for Voxbeam though. I have set up an account with them.
But all calls are rejected. Here is what I have:
SIP server: sbc.voxbeam.com
port: 5060
user: mylogin@gmail.com
password: mypassword
no STUN server is configured.
I dialed trying either the standard or premium access lines (ie 0011101 and 0011103 prefixes).
The Obi reports: Register Failed: 500 Method not allowed (server=95.211.119.251:5060; retry in 25s)
In addition to the above I do have couple more questions:
1. what do I need to do to spoof a caller ID of my choice when using Voxbeam?
enter it in URI? or any other mechanism?
2. I'd like to simplify the dialed digits when using the Voxbeam trunk and to normalize the
dialing to that of other services (this is mostly for my other "customers" in the house that
have little tolerance for new dialing habits). So suppose I want the following:
if I dial on the handset **2 011 nn 1234567890 (nn=country code), the obi
converts it to appropriate # for the voxbeam trunk that will look like:
0011101 nn 1234567890
3. Does Voxbeam require SIP registration or just authentication ?
thanks
L.
I edited previous posting to correct the info that the Obi was not registering with Voxbeam actually.
Obitalk was saying one thing but when I went to the device itself it was giving me the real error.
L.
Quote from: lk96 on January 21, 2012, 11:13:52 AM
I dialed trying either the standard or premium access lines (ie 0011101 and 0011103 prefixes).
The Obi reports: Register Failed: 500 Method not allowed (server=95.211.119.251:5060; retry in 25s)
Have you listed your IP address at Voxbeam?:
Authentication
Authenticating your calls with Voxbeam couldn't be simpler; all that we need to know is the IP address(es) that you'll be sending calls from. You can add and remove IP addresses at any time using your Voxbeam account's settings page.
Quote from: lk96 on January 21, 2012, 11:13:52 AM
2. I'd like to simplify the dialed digits when using the Voxbeam trunk and to normalize the
dialing to that of other services (this is mostly for my other "customers" in the house that
have little tolerance for new dialing habits). So suppose I want the following:
if I dial on the handset **2 011 nn 1234567890 (nn=country code), the obi
converts it to appropriate # for the voxbeam trunk that will look like:
0011101 nn 1234567890
The following will prepend 0011101 to all calls sent using SP2:
Service Providers -> ITSP Profile B -> General -> DigitMap:
(<0011101>(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1aaa>[2-9]xxxxxx|<011:>xx.)|(Mipd)|[^*#]@@.'@'@@.)
where aaa is your local (US) area code.
In addition to what RonR posted, please note:
1. Voxbeam will not accept a registration (there is no need, as they don't sell phone numbers or incoming service of any kind). So, if you put them in SP1 or SP2, turn off X_RegisterEnable for the service.
2. Voxbeam requires proper NAT mapping. In your setup, that does need STUN. Set STUNEnable and set a working STUN server in STUNServer (mine is currently set to stun.ekiga.net).
Quote
Have you listed your IP address at Voxbeam?:
Yes, I had done that couple days back when I opened the Voxbeam account. And
verified that my public address matches the one I entered on my Voxbeam account.
Quote from: Stewart on January 21, 2012, 12:05:12 PM
In addition to what RonR posted, please note:
1. Voxbeam will not accept a registration (there is no need, as they don't sell phone numbers or incoming service of any kind). So, if you put them in SP1 or SP2, turn off X_RegisterEnable for the service.
Interesting they are doing strict checking. I have now disabled that option so
the Obi is not attempting to register.
Quote
2. Voxbeam requires proper NAT mapping. In your setup, that does need STUN. Set STUNEnable and set a working STUN server in STUNServer (mine is currently set to stun.ekiga.net).
I have done so as per your suggestion.
After taking care of all of the above, I still get "fast" rejection of any calls I try to make over
the SP2 trunk where I placed the Voxbeam account.
Any other ideas or things to check?
L.
Quote from: lk96 on January 21, 2012, 09:04:56 PM
After taking care of all of the above, I still get "fast" rejection of any calls I try to make over
the SP2 trunk where I placed the Voxbeam account.
Any other ideas or things to check?
Look at Call History, both for what error you got, and whether the correct number was sent to Voxbeam.
I got it working now.
Apparently the problem had to do with the fact that my login name
at the voxbeam site and the name that the SIP service was expecting are different.
on the voxbeam site my login is: myname@gmail.com
However, when I setup the SP2 voice service, I need to use only the "myname" part (and remove the @gmail.com).
In any case this is working now. I also noticed that if I enter my desirable caller ID
in the URI, the caller ID is delivered appropriately.
Tomorrow, will work to setup the dialing rules and simplifications as described by RonR
so that I have a unified dialing plan for the house users.
thanks much to both of you again for your help.
L.
In case someone is interested in some subjective and relatively simple voice quality assessment
of EasyVoip vs VoxBeam ...
I did couple of test calls where I used a callback from Obi to one of my two cell phones (which
is with Tmobile). Then from the AA I dialed out to my second cell phone (that is with AT&T).
I tried two basic scenarios. In scenario #1, the calls were connected over EasyVoip.
In the second case the calls went over Voxbeam.
So the call paths were like this:
Scenario #1: mobile #1 <----(over Easyvoip) ---> Obi <---(over EasyVoip) ---> mobile #2
Scenario #2: mobile #1 <----(over Voxbeam) ---> Obi <---(over Voxbeam) ---> mobile #2
I did a wall clock measurement of the voice latency from mobile #1 to mobile #2 in each case.
In the first scenario, the latency was really high ... about 1sec or a bit over 1sec.
In the 2nd scenario the latency was a bit less than 500msec. Measurements were subjective
based on simple listening.
Given that the call was from Mobile to mobile, it is estimated that even without any network
delay, mobile-side processing introduces up to 200-250msec of delay. So as much delay will
be present no matter who the provider is.
I found this quite significant. Voice quality studies have found that when the voice latency is greater
than around 300-400ms, the quality of the conversation degrades as the two speaker
tend to step on each other (double talk).
From above, it seems that at least in the test calls I performed, Easyvoip introduces
significant latency. Depending on the location of call participants it may, it may not create
for challenging experience. For example, during a recent call I did (using above method)
to a mobile in France, the delay exceeded 1.5 seconds. That made for a tricky phone exchange.
I'm located in the US so the above measurement may not hold true in other continents.
L.
Quote from: RonR on January 21, 2012, 11:37:15 AM
The following will prepend 0011101 to all calls sent using SP2:
Service Providers -> ITSP Profile B -> General -> DigitMap:
(<0011101>(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1aaa>[2-9]xxxxxx|<011:>xx.)|(Mipd)|[^*#]@@.'@'@@.)
where aaa is your local (US) area code.
I'm getting strange digit formations that are sent out to the selected service (SP2) with above syntax.
The exact digitmap I'm using for SP2 is shown below. In addition to substituting 011 with the Voxbeam prefix,
I'm also adding/replacing numbers that start with "00" with Voxbeam prefix as well:
(<0011101>(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<011:>xx.|<00:>xx.|xx.)|(Mipd)|[^*#]@@.)
Below is representative behavior I see at the call records.
Example:
I dialed: **2301234567890
digits shown at PHONE1 terminal: **20011101301234567890
digits shown at SP2 terminal: 001110111101301234567890
It seems that for some reason the 0011101 prefix was added to the phone terminal digits before the SP2 digitmap was applied. And when the SP2 digitmap was applied, the "011" pattern was removed and
a second 0011101 prefix was attached.
The digit map and outbound call route info for PHONE are the defaults.
I can't seem to figure out why Obi shows that the PHONE terminal added the first
instance of the 0011101 prefix.
L.
PS: I tested also with an SP2 digitmap where I removed all the 00 and 011 handling part.
I see again that the 0011101 prefix is shown in the PHONE1 terminal digits.
I made a mistake and you compounded it with your 00xx. rule.
Use this instead:
Service Providers -> ITSP Profile B -> General -> DigitMap:
(<+:0011101>xx.|<+>(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<011:>xx.|<00:>xx.)|(Mipd)|[^*#]@@.'@'@@.)
So the logic with your revised rule is:
1. handle the rules in the inner parenthesis first (ie if you see 011 remove it).
2. add a placeholder symbol in front of the modified string of digits
3. substitute the "+" placeholder with the desired voxbeam prefix.
Do I have this right?
If so, then the above syntax is no obvious from the admin documentation.
L.
Quote from: lk96 on January 23, 2012, 03:00:38 PM
Do I have this right?
Yes. The '+' is added when the PHONE Port DigitMap is evaluated. The '+' is replaced by 0011101 when the PHONE Port OutboundCallRoute is evaluated.
Quote from: lk96 on January 23, 2012, 03:00:38 PM
If so, then the above syntax is no obvious from the admin documentation.
There's a lot about the OBi that isn't obvious from the admin documentation. :(
OK, confirming that the revised rule worked. Thanks.
If I have it right, there is no such thing as recursive evaluation of the rule.
You simply exploit the simple fact that when **2 is dialed, Msp2 will be applied
to the dialed number which is 011301234567890 and will convert it to: **2+301234567890.
And at that point,the OutboundCallRoute will kick it, it will remove the **2, and
it will also match the "+" symbol and Msp2 is used again.
And it is at that point that the final expansion to include the desired prefix, takes place.
interesting ...
L.
Suppose I use SP2 to get a callback from the AA. I have already configured
the SP2 digitmap as we discussed before.
What I noticed is that when I get the callback from the AA through SP2, there was no digitmap processing
performed: ie, if I have set aa(sp2(1234567890)) to get a call back to that #, and given
that SP2 is the voxbeam trunk, what I see in the call record is that the number dialed
on SP2 is just the 1234567890 part and not 0011101 1234567890 as I'd expect.
Would you have an idea why there is different digit handling in this case? Does the above
make sense?
thanks
L.
Calls using TK format [(sp2(1234567890)] don't use a DigitMap or OutboundCallRoute, so you would have to include whatever you want to go out: SP2(001110112341234567).
Yes, I figured that after more tests. However I did try something else that also didn't work.
I defined a user-defined digitmap that was called: Mvoxmap
If I use a term like: {(Mvoxmap):aa($1)} in the inboundcallrules, the incoming
call on SP2 that is supposed to trigger the callback fails (I get a busy tone).
And the Obi call records do not include any trace of that call.
However, if instead, I cut&paste the exact same Mvoxmap digit map directly in the inboundcallrule,
it works properly and all digit processing is done as per the rule used.
Going by the documentation I expected that I can use the (Mvoxmap) reference directly in the inbound rule.
However in my case it seems that Obi totally ignores/rejects it.
It feels like a bug to me but again I'm not 100% sure if this handling was intentional or just buggy behavior.
For the time being, I have the above work-around that works ok.
thanks again
L.
Quote from: Shammi on July 01, 2012, 09:39:37 AMHi there,
I am not sure how to find my IP address. Is this obihai's IP address that we get by dialing ***1, the public IP address that we can find like, by clicking here http://whatismyipaddress.com/
Thanks
Hi Shammi,
I'm assuming you are using a OBI100 or OBI110. When you press ***1, this tells you your OBI's IP Address on your Local (private) Network; this is not your public IP. To determine your Public IP Address, you can use the website that you mentioned above (http://whatismyipaddress.com/).
I'm not sure which one you are trying to determine, but those are the methods to determine your OBI's local address or your public address.
Does this help?
pc44
Quote from: Shammi on July 01, 2012, 09:39:37 AM
Hi there,
I am not sure how to find my IP address. Is this obihai's IP address that we get by dialing ***1, the public IP address that we can find like, by clicking here http://whatismyipaddress.com/
Thanks
When it comes to Voxbeam, your public IP address (ie the one returned by the http://whatismyipaddress.com
service) is needed. They seem to use it to validate the end points that Voxbeams SIP trunks can be used at.
You can also find your public IP address by looking at your router WAN configuration or information page.
L.