October 15, 2019, 10:02:52 pm *
Welcome, Guest. Please login or register.
News:
 
   Forum Home   Search Login Register OBiTALK  
Pages: [1]
  Print  
Author Topic: Setting up Obi110 for Brazil PSTN + GVoice + SIP  (Read 5430 times)
Breno
Newbie
*
Posts: 6


« on: November 18, 2012, 08:36:12 pm »

Hello, I bought an Obi110 and have it currently setup for usage with my PSTN line, Google Voice and FreeVoipDeal (a betamax provider).

Everything is working fine besides some latency.
I fixed my caller id problem by changing the line port calleridmethod to dtmf, and the tone by this topic - http://www.obitalk.com/forum/index.php?topic=2015.msg12744#msg12744
I also managed to reduce the delay a little by using some tips from here - http://www.toao.net/500-mangos-guide-to-configuring-an-obi100-obi110-and-obi202-ata

But Im trying to get a proper Digitmap to work but so far i got no success.

This is my digitmap for the line port
(1xx|[34]00xxxx|0800xxxxxxx|1xxxx|[2-9]xxxxxxx|90xx.)

1- Emergency calls
2- Calls to special numbers
3- Toll free calls
4- Calls to providers
5- Local Calls
6- Collect Calls

What I need now is to make this work:
1 - Calls to another state: 0xx xxxxxxx (10 digits) - Call through SP2/FreeVoipDeal, also that first 0 would have to act as "0055".
2 - Calls to US: 001 xxx xxxx - Call through SP1/Google Voice
3 - Calls to any other country: 00xx. go through FreeVoipDeal
4 - Calls to mobile phones: "9xxx xxxx" or "8xxx xxxx" or even "0xx 9xxx xxxx" / "0xx 8xxx xxxx" to those in other states. - Call through SP2/FreeVoipDeal (again adding "0055" instead of "0" and "005584" before 9 or 8 for local calls).

Maybe i would also need some other rules but thats what i can remember now.
I also need to get the FreeVoipDeal callerid and the Automated Assistant working but thats for another topic.
Logged
ianobi
Hero Member & Beta Tester
*****
Posts: 1831


« Reply #1 on: November 19, 2012, 03:32:54 am »

Breno,

Welcome to the forum  Smiley

A lot depends on how your PrimaryLine is set up. The default for OBi110 is:

Physical Interfaces -> PHONE Port -> PrimaryLine : PSTN Line

This means that you do not need to dial **8 to use the PSTN line. I will assume that is the case.

I will have a go at the first part you asked for: 1 - Calls to another state: 0xx xxxxxxx (10 digits) - Call through SP2/FreeVoipDeal, also that first 0 would have to act as "0055". If it makes sense to you, then have a go at the others or come back and Iíll try some more.

Take your existing Line Port DigitMap:

(1xx|[34]00xxxx|0800xxxxxxx|1xxxx|[2-9]xxxxxxx|90xx.)

Change to:

(<0:**20055>x[1-9]xxxxxxx|1xx|[34]00xxxx|0800xxxxxxx|1xxxx|[2-9]xxxxxxx|90xx.)

I made assumptions following very little research Ė with calls to another state the third digit cannot be  a ď0Ē. This means we can avoid conflict with 0800 numbers.

First rule: If a number starts with a 0, the third digit is not a 0 and is ten digits long, then replace the leading 0 with **20055. When this number, **20055xxxxxxxxx, is processed by the Phone Port OutboundCallRoute, the **2 will be removed and 0055xxxxxxxxx will be sent out to Service Provider 2. To make this work a rule 0055xxxxxxxxx will also need to be in the Service Providers -> ITSP Profile B -> General -> DigitMap (which is Msp2).

Simple   Cheesy   To be fair that is unusually difficult. I hope my assumptions were correct. If not, then I would need more info on Brazilian number formats.

There is a conflict in your original DigitMap as it contains these two rules: 1xx and 1xxxx. If you dial 1xxxx fairly slowly the 1xx rule will match it after 1xx has been dialled. The way we normally deal with this is to change the shortest rule by adding a delay Ė 1xxS4 Ė this gives more time for users dialling 1xxxx. The problem is that it delays your emergency number calling. Can any other digits be used to avoid conflicts Ė maybe the second digits can be different?

Anyhow, thatís more than enough to think about for one post  Smiley

« Last Edit: November 19, 2012, 03:36:33 am by ianobi » Logged
ianobi
Hero Member & Beta Tester
*****
Posts: 1831


« Reply #2 on: November 19, 2012, 03:47:42 am »

More thoughts about emergency calls! In both of these:

Physical Interfaces -> PHONE Port -> DigitMap

Physical Interfaces -> PHONE Port -> OutboundCallRoute

Replace 911 with 1xx

Then remove 1xx from the Line Port DigitMap.

These changes will remove the conflict and means 1xx calls are sent directly to Line Port with no processing via DigitMaps.

Logged
Breno
Newbie
*
Posts: 6


« Reply #3 on: November 19, 2012, 04:15:43 am »

Thank you so much Smiley
I'll try your suggestions as soon as i get home.
Btw the emergency calls are all "19x" here but theres also other public services that goes in the 3 digit category (1xx). Should I leave "19x" at phone port?

More thoughts about emergency calls! In both of these:

Physical Interfaces -> PHONE Port -> DigitMap

Physical Interfaces -> PHONE Port -> OutboundCallRoute

Replace 911 with 1xx

Then remove 1xx from the Line Port DigitMap.

These changes will remove the conflict and means 1xx calls are sent directly to Line Port with no processing via DigitMaps.


Logged
ianobi
Hero Member & Beta Tester
*****
Posts: 1831


« Reply #4 on: November 19, 2012, 05:40:08 am »

I would just go with getting rid of 1xx out of the Line Port DigitMap and letting all three digit numbers starting with 1 be sent direct to the Line Port with no DigitMap involved. This way you can be sure there is minimal delay in sending emergency calls to line. That is why the 911 was not in the Line Port DigitMap to start with (default value for North American emrgency calls).

It does raise an important point about number conflicts - any differences that make a number range unique is very useful when dealing with DigitMaps.
Logged
Breno
Newbie
*
Posts: 6


« Reply #5 on: November 19, 2012, 10:56:55 am »

This is my current dial plan and it seems to be working great so far:

(<0:**20055>x[1-9]xxxxxxxx|[34]00xxxx|0800xxxxxxx|1xxxx|[2-7]xxxxxxx|<8:**20055848>xxxxxxx|<9:**20055849>xxxxxxx|90xx.|<001:**1>[2-9]xx[2-9]xxxxxx|<00:**200>xx.)

1 - Calls to other states (SP2)
2 - Calls to special numbers (PSTN)
3 - Calls to toll free (PSTN)
4 - Calls to providers customer service (PSTN)
5 - Calls to local landlines (PSTN)
6 - Calls to local mobiles starting with 8 (SP2)
7 - Calls to local mobiles starting with 9 (SP2)
8 - Collect calls (PSTN)
9 - Calls to US (SP1)
10 - Calls to other countries (SP2)

Could I simplify this digitmap? Or should I change anything else?
As for the SP2 callerid it appears to work fine when i call to landlines (my pstn number shows up in the phone of the person im calling) but when i call to a mobile phone it shows up an access number from rio de janeiro. Does anyone that use betamax has any experience on this?

I have disabled all the obitalk features and im using only the local configuration page right now (had to do everything from scratch) obitalk was giving me lots of red exclamation marks and conflicting with the local configuration.

I used this page to configure Google Voice - http://www.obihai.com/itspConfiguration/itspConfiguration-googlevoice.html
And for the SP2 provider i did it manually.

Now about the auto attendent feature how does it work? How do I configure it without obitalk? Can it be used while the phone is making or receiving PSTN calls? Does it work through the ObiON iphone app (connecting through internet instead of call back)?
Logged
ianobi
Hero Member & Beta Tester
*****
Posts: 1831


« Reply #6 on: November 19, 2012, 11:20:53 am »

You certainly got your head around digit maps quickly  Smiley

I'm not sure about this rule:
<001:**1>[2-9]xx[2-9]xxxxxx
It probably needs to be:
<001:**11>[2-9]xx[2-9]xxxxxx
to give the leading 1 and eleven digits that GV needs.

The red exclamation marks are not a problem, they just show that you have changed a setting and that you are in control of that setting.

The aa settings are simply a matter of changing InboundCallRoutes to include rules such as {(12345678912):aa},{ph} where 12345678912 is a Caller ID to which you wish to give access to the aa.

Have a read about aa here in forum and in OBiDeviceAdminGuide and I will be back tomorrow - or many helpful people nearer your time zone may be here any minute now  Smiley
Logged
Breno
Newbie
*
Posts: 6


« Reply #7 on: November 21, 2012, 07:20:19 am »

Here is my current line port digitmap:

(<0:**20055>x[1-9]xxxxxxxx|0800xxxxxxx|10xxx|105x|[2-4]xxxxxxx|<8:**20055848>xxxxxxx|<9:**20055849>xxxxxxx|90xx.|<001:**1>[2-9]xx[2-9]xxxxxx|<00:**200>xx.)

I removed the rule for special numbers (starting with 300 and 400) because it would conflict with regular numbers so its covers everything on [2-4]xxxxxxx. Added "105x" that is also used for some mobile providers customer service.
Logged
ianobi
Hero Member & Beta Tester
*****
Posts: 1831


« Reply #8 on: November 21, 2012, 09:06:01 am »

Brazil must be the most challenging country in the world to design a DigitMap for  Smiley

I was wrong in my previous comments concerning <001:**1>[2-9]xx[2-9]xxxxxx The rule works because of Msp1:
Service Providers -> ITSP Profile A -> General -> DigitMap:
(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|(Mipd)|[^*]@@.'@'@@.)
This is where the leading 1 gets added: <1>[2-9]xxxxxxxxx
I would remove 011xx.|(Mipd)|[^*#]@@. The 011xx. is not wanted and I donít believe GV allow sip uri dialling (anything@anywhere) format which is what the other rules are for. Always be wary of this rule [^*#]@@. As far as digits are concerned it is the same as xx.

There is a possible conflict here |10xxx|105x| If someone dialled 105xx quite slowly it could be matched by 105x The normal way to avoid this is by adding a delay to the shorter rule like so:
|10xxx|105xS4| This gives a user up to four seconds to dial the last digit in the first rule before the second rule matches it.

The Auto Attendant can be used in various ways, but to get to the aa the Caller ID must be in a rule in an InboundCallRoute e.g:
Line Port InboundCallRoute {(12345678912):aa},{ph} where 12345678912 is a Caller ID to which you wish to give access to the aa. Change the rule to {(12345678912):aa($1)},{ph}, then if you clear down before aa answers, aa will call you back and offer its service to you.

To use aa from OBiON a rule like this is needed:
OBiTALK Service > InboundCallRoute > {(290123456):aa},{ph} where 290123456 is your OBioN softphone number.
« Last Edit: November 21, 2012, 09:08:56 am by ianobi » Logged
QBZappy
Hero Member & Beta Tester
*****
Posts: 2317



« Reply #9 on: November 21, 2012, 09:13:31 am »

... then if you clear down before aa answers, ...


"clear down" you Brits talk funny!!!  Learn to speak Canadian. (hang up) Cheesy
Logged

Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.
ianobi
Hero Member & Beta Tester
*****
Posts: 1831


« Reply #10 on: November 21, 2012, 09:42:40 am »

I'll have you know that I failed at the same school Shakespeare failed at  Cool
Logged
Breno
Newbie
*
Posts: 6


« Reply #11 on: November 26, 2012, 10:03:37 am »

I have a problem Tongue

I want to call a number from another state using my pstn line instead of voip, normally **8 would work but when i dial **801131112222 for example it call goes to **8**201131112222 instead.

How do I fix that? Or better yet, how do I make calling through PSTN directly more simple like just #01131112222?

Thanks!
Logged
ianobi
Hero Member & Beta Tester
*****
Posts: 1831


« Reply #12 on: November 26, 2012, 10:57:56 am »

Iím assuming that Phone Port PrimaryLine is PSTN and your Line Port DigitMap is:

(<0:**20055>x[1-9]xxxxxxxx|0800xxxxxxx|10xxx|105x|[2-4]xxxxxxx|<8:**20055848>xxxxxxx|<9:**20055849>xxxxxxx|90xx.|<001:**1>[2-9]xx[2-9]xxxxxx|<00:**200>xx.)

If you dial 01131112222 then this rule <0:**20055>x[1-9]xxxxxxxx should match it and transform it into **200551131112222. Then it should be sent out on sp2 as 00551131112222. Check in Call History via the web page.

To stop that rule matching the numbers starting 0113, you need to find some difference that you can build into the <0:**20055>x[1-9]xxxxxxxx rule. Then you can have a rule such as 0113xxxxxxx in your Line Port DigitMap.

Iím not around much this week, but I will try to look in when I can. As a temporary solution you can press # before dialling. This will give you PSTN dial tone so you can dial direct with no OBi involvement.

Logged
Breno
Newbie
*
Posts: 6


« Reply #13 on: April 17, 2014, 11:32:15 am »

Recently i changed my phone plan to a cheaper one with no minutes included just pay as you go, so I changed my digitmap to redirect all calls (except us calls) to SP2 (currently freevoipdeal/betamax).

Can this digitmap be simplified? I think its too big.

(<0:**20055>xx[2-9]xxxxxxxS3|0800xxxxxxx|10xxx|105x|<2:**20055842>xxxxxxx|<3:**20055843>xxxxxxx|<4:**20055844>xxxxxxx|<8:**20055848>xxxxxxx|<9:**20055849>xxxxxxx|90xx.|<001:**1>[2-9]xx[2-9]xxxxxx|<00:**200>xx.)

Also as Google Voice is no longer going to work next month which provider do you guys recommend me with cheap rates to brazil? It would be good if i could spoof the called id with my local line number or the gvoice number. Also a pay as you go plan is preferred.

Thanks!
Logged
ianobi
Hero Member & Beta Tester
*****
Posts: 1831


« Reply #14 on: April 18, 2014, 03:49:58 am »

I think you can put all your local calling codes into one rule <**2005584>[23489]xxxxxxx

So you would have:

Physical Interfaces > LINE Port > DigitMap:
(<0:**20055>xx[2-9]xxxxxxxS3|0800xxxxxxx|10xxx|105x|<**2005584>[23489]xxxxxxx|90xx.|<001:**1>[2-9]xx[2-9]xxxxxx|<00:**200>xx.)

It might also be worth having another look at your Msp2. It could be quite simple such as:

Service Providers > ITSP Profile B > General > DigitMap:
(0055xxxxxxxxxx|<0:0055>xx[2-9]xxxxxxxS3|<005584>[23489]xxxxxxx|00xx.S4)

This allows for the automatic routing controlled by your Primary Line (Mli) and also allows you to manually dial **2 followed by local/national/international should you wish Ė this might be useful for testing.

Iím not in Brazil, so you will have to be chief tester on this one!


I donít live in North America, so Iím not going to get involved in the Google Voice replacement debate Ė thereís lots of posts with lots of advice on that subject already   Cheesy
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC