News:

The OBiTALK service has reached it's End of Life period and will be decommissioned as of October 31st, 2024. More information can be found at this link https://support.hp.com/us-en/document/ish_10969583-11049883-16

Main Menu

Obi110 in United Arab Emirates

Started by Riyas, September 08, 2011, 02:38:56 AM

Previous topic - Next topic

Riyas

Hello !

I am very happy with Obi. I recommend it to all my family & friends. One of my friend who is based in Abu-dhabi (United Arab Emirates) is interested by Obi110. But in this country, SIP protocol (not only port 5060) is blocked by ISP. Google talk is working in UAE. We want to know if we can use Obi for google talk.

If I create a Circle Of Trust with him, is it possible for him to place SIP calls through My Sip account registered in France ?

I don't know whether it's clear.

Thanks for your help guyz

earthtoobi

#1
i have a similar use case too.
Obitalk Voice is working in UAE.
google chat works for Incoming calls.
for Outgoing calls ,i think google rates apply.am yet to check this though.
ObiApp also works and can be used with Xlite.

So, yes, he can bridge his calls via your Obi box.

Riyas

Ok, thanks for your feedback. Now I need help to configure ;D

I have 2 Obi110. One in France (Obi1) and One in Dubai (Obi2)

All I want to do is :

1) Setup Voice Gateway 3 in France (As my friend can't use SIP accounts directly in Dubai)
2) If my friend calls numbers starting from 01, 02, 03, 04, 05, 00919 => I want his calls routed through my VG3 (Obi1).
3) If my friend calls numbers starting from 26 (local numbers), I want his calls go through local PSTN line (Obi2).

I don't know how to configure both OBI's. I want to use One Stage Dialling.

Is it possible to do that ? Thanks in advance for your help guys.

RonR

Riyas,

Do you already have a VoIP provider configured on Voice Gateway3 of OBi #1 with outbound calls working on it?  If so, does it currently handle numbers starting with 01, 02, 03, 04, 05, and 00919.  If not, what format does the provider expect (country code + number, 011 + country code + number, or what)?

If not, do you have SP1 and/or SP2 configured for SIP at this point?

If not, is SP1 and/or SP2 unused at this point.

Please describe the current configuration and status of both OBi's in great detail.

Riyas

Hi RonR,

Thanks for your reply.

>>>>>>>Do you already have a VoIP provider configured on Voice Gateway3 of OBi #1 with outbound calls working on it?  If so, does it currently handle numbers starting with 01, 02, 03, 04, 05, and 00919.

Yes VG3 is configured and working properly. This is my Digitmap for VG3 : (0[1-5]xxxxxxxxS0|0091xxxxxxxxxxS0)

>>>>>>> If not, do you have SP1 and/or SP2 configured for SIP at this point?

Yes SP1 is configured with sip account and SP2 with Google Talk.
In Obi#1, I can maybe remove google talk and configure SP2 for Obi#2.
Obi#2 is brand new and is not at all configured. Thanks again for your help

RonR

#5
Hopefully, these are the only changes you need to make to either OBi:


OBi #1

Voice Services -> OBiTALK Service -> InboundCallRoute : {200000002>(Mvg3):vg3},{ph}

where 200000002 is the OBiTALK number of OBi #2


OBi #2

Physical Interfaces -> PHONE Port -> OutboundCallRoute:

{(<+:2*>xx.):pp},{([1-9]x?*(Mpli)):pp},{(<#:>|911):li},{**0:aa},{***:aa2},
{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mpli):pli}

Physical Interfaces -> LINE Port -> DigitMap : (26xx.|<+>0[1-5]xxxxxxxx|<+>00919xxxxxxxxx)

User Settings -> Speed Dials -> 2 : PP(ob200000001)

where 200000001 is the OBiTALK number of OBi #1

Riyas

RonR,
Thanks for your help. I've followed your instruction.
If I dial speed dial 2 from Obi#2, it wasn't working (No service available). Then I've added **9 before obi number (**9 200000001). Now call gets connected to Obi#1.

But If dial 0177755xxx from Obi#2, it's not working. It rings my Obi#1. Here my call history.

Call 1      09/17/2011                   12:49:58   
Terminal ID   PHONE1         P2P1
Peer Name      
Peer Number   2*0177755xxx         2*2*0177755xxx
Direction          Outbound                      Outbound
12:49:58          New Call   
12:50:08         Call Connected
12:50:27         End Call

What I want is, If my friend in Dubai dials 0177755xxx, it will go through my VG3 (One stage dialling).

Thanks

RonR

I screwed up.  Try the revised OBi #2 settings.

Sorry 'bout that!

Riyas

RonR,

Thanks again for your help. Unfortunately, I still have the same problem. When I dial 0177755xxx or 00919xxxxxxxxx, my call is ringing at Obi#1 (Obi in France).

Terminal ID        PHONE1                 P2P1
Peer Name      
Peer Number   +0177755xxx   2*0177755xxx
Direction           Outbound                   Outbound
23:14:05   New Call   
23:14:11   Call Connected
23:16:11   End Call

I don't know if I need to do anything on Obi#1...

I've also looked at your post here : http://www.obitalk.com/forum/index.php?topic=1103.0

Can this method work for me ?

Sorry for troubling you again and again.


RonR

Quote from: Riyas on September 17, 2011, 11:57:59 AM
I don't know if I need to do anything on Obi#1...

Did you configure this in OBi #1 (the OBI with VG3)?:

Voice Services -> OBiTALK Service -> InboundCallRoute : {200000002>(Mvg3):vg3},{ph}

where 200000002 is the OBiTALK number of OBi #2

Make sure you have the right OBiTALK number for OBi #2 in place of 200000002.

The Call History in OBi #2 (Dubai) looks correct now.  For some reason, the InvoundCallRoute rule in OBi #1 isn't matching the OBiTALK number or the outgoing call pattern.  What does the Call History in OBi #1 show when the call goes to the PHONE Port instead of VG3?

RonR

Another thought...

Are both OBi's running the same version firmware?  According to obi-support2, there are interoperability problems between v1.3 and earlier versions in the area of OBiTALK number authentication.

Riyas

Quote from: RonR on September 17, 2011, 12:09:38 PM
Did you configure this in OBi #1 (the OBI with VG3)?:
Voice Services -> OBiTALK Service -> InboundCallRoute : {200000002>(Mvg3):vg3},{ph}
where 200000002 is the OBiTALK number of OBi #2
Make sure you have the right OBiTALK number for OBi #2 in place of 200000002.

Yes, this part is configured properly.

This is Obi#1 call history :

Call 1   09/17/2011    22:15:46   

Terminal ID   P2P1      PHONE1
Peer Name        Dubai   
Peer Number   200996xxx   
Direction        Inbound        Inbound
22:15:46   Ringing   
22:15:50   Call Connected
22:16:38   End Call

Quote from: RonR on September 17, 2011, 12:42:03 PM
Another thought...
Are both OBi's running the same version firmware?  According to obi-support2, there are interoperability problems between v1.3 and earlier versions in the area of OBiTALK number authentication.

Both software versions are : 1.2.1 (Build: 2384)

RonR

I assume the InboundCallRoute rules are : {200996xxx>(Mvg3):vg3},{ph}

The problem is this VG3 rule not executing because (1) the OBiTALK number (200996xxx) isn't matching or (2) the passed called number (0177755xxx or 00919xxxxxxxxx) isn't matching the Mvg3 DigitMap.

It appears the correct number is starting out at OBi #2 (2*0177755xxx).  OBi #2 should remove the '2*' and  send the call to the OBi number stored in Speed Dial 2.  0177755xxx should arrive at OBi #1 from 200996xxx.  200996xxx should match the COT authentication, 0177755xxx should match the Mvg3 DigitMap, and the call should be sent out vg3.

You might try:

{200996xxx:vg3},{ph}

to make sure the OBiTALK number authentication is matching.  Assuming the call does not go to the PHONE Port, check the Call History to see what the called number actually was.

Also try:

{200996xxx>(xx.):vg3},{ph}

to see if the problem is with the called number not matching Mvg3.  Assuming the call does not go to the PHONE Port, check the Call History to see what the called number actually was.

If all else fails, try:

{vg3},{ph}

Assuming the call does not go to the PHONE Port, check the Call History to see what the called number actually was and where it came from.

RonR

Another thought...

Try taking the S0's out of the VG3 DigitMap.  I wouldn't think those should get in the way, but you never know.  They're not part of the InboundCallRoute syntax but I would hope the OBi would ignore them.

Riyas

Quote from: RonR on September 17, 2011, 01:59:44 PM
You might try:

{200996xxx:vg3},{ph}
{200996xxx>(xx.):vg3},{ph}

Both settings are working for French numbers.  :) 0177755xxx is working great. Calls go through with great quality. Thanks for your help.

But I still have one issue.  :-[ When I dial an indian number (0091xx.) from Obi#2, I can see in OBI#1 that calls are dialled normally. But it keeps ringing (kind of fake ringing, I've called my relatives in India from my mobile, they told me that they didn't recieve any call). But If I dial this number directly from Obi#1, calls are connected correctly. Settings are same in call history. I don't understand. I am still searching...

Quote from: RonR on September 17, 2011, 02:13:48 PM
Another thought...

Try taking the S0's out of the VG3 DigitMap.  I wouldn't think those should get in the way, but you never know.  They're not part of the InboundCallRoute syntax but I would hope the OBi would ignore them.

I've removed this S0 but the result is same

RonR

Quote from: Riyas on September 17, 2011, 03:14:48 PM
Quote from: RonR on September 17, 2011, 01:59:44 PM
You might try:

{200996xxx:vg3},{ph}
{200996xxx>(xx.):vg3},{ph}

Both settings are working for French numbers.  :) 0177755xxx is working great. Calls go through with great quality. Thanks for your help.

Those were meant for testing and not as the ultimate solution.

Those rules allow ANY number to be sent out VG3 whether or not it meets VG3's DigitMap rules (the VG3 DigitMap isn't used).

Since they work, this rule:

{200996xxx>(Mvg3):vg3}

should also work assuming the called number meets the Mvg3 DigitMap rule.

There's still a mystery.

RonR

#16
Riyas,

If you're interested in trying to solve the mystery, here's some more things to test:

1. Put the original OBiTALK InboundCallRoute rules back in place:

{200996xxx>(Mvg3):vg3},{ph}

and verify that calls go to the PHONE Port instead of VG3.

Then temporarily replace the VG3 DigitMap with:

(xx.)

Calls should now go to VG3 again since this matches any digit string, proving that the VG3 DigitMap is being referenced.

2. Change the OBiTALK InboundCallRoute rules to:

{200996xxx>(0[1-5]xxxxxxxx|0091xxxxxxxxxx):vg3},{ph}

Calls should still go to VG3 as this is using the VG3 DigitMap embedded in the rule instead of referencing it indirectly.

Hopefully, something will jump out at some point to indicate what's going wrong.

Riyas

Quote from: RonR on September 17, 2011, 05:03:39 PM
Riyas,

If you're interested in trying to solve the mystery, here's some more things to test:

1. Put the original OBiTALK InboundCallRoute rules back in place:

{200996xxx>(Mvg3):vg3},{ph}


It's strange, with this setting ({200996xxx>(Mvg3):vg3},{ph}) my calls to 0177755xxx are working properly. Calls are routed to VG3. But calls to India (0091xx )  are not working. I've tried to change digitmap to xx. without success

Riyas

I still have some issue to call India. Now I am trying to follow this guide :

http://www.obitalk.com/forum/index.php?topic=1103.0

These are my settings in both units:

Voice Services -> OBiTALK Service -> InboundCallRoute:

{(Mcot)>(Mli):li},{(Mcot)>(<*1:>(Msp1)):sp1},{(Mcot)>(<*2:>(Msp2)):sp2},{(Mcot)>(<*3:>(Mvg3)):vg3},
{(Mcot)>(<*8:>(Mli)):li},{(Mcot)>(<*9:>(Mpp)):pp},{(Mcot)>(<**1:>(Msp1)):sp1},{(Mcot)>(<**2:>(Msp2)):sp2},{(Mcot)>(<**3:>(Mvg3)):vg3},{(Mcot)>(<**8:>(Mli)):li},{(Mcot)>(<**9:>(Mpp)):pp},{(Mcot):aa},{ph}

User Settings -> User Defined Digit Maps -> User Defined Digit Map:

Label : cot
DigitMap : (200000002|200000001)

PHONE Port and Auto Attendant DigitMap's, changed from [1-9]x?*(Mpli) to [1-9]x?*@@.
PHONE Port and Auto Attendant OutboundCallRoute's, changed from {([1-9]x?*(Mpli)):pp} to {([1-9]x?*@@.):pp}

Speed Dial #2 : PP(ob200000002)
Speed Dial #3 : PP(ob200000001)

Speed dial #4 in Obi#2 : 2 **3 0177755xxx

My call goes directly to AA. I don't know what I am doing wrong.

Except for Speed Dial#4 in Obi#2, all settings are same in both units

RonR

#19
Quote from: Riyas on September 18, 2011, 04:07:06 AM
It's strange, with this setting ({200996xxx>(Mvg3):vg3},{ph}) my calls to 0177755xxx are working properly. Calls are routed to VG3. But calls to India (0091xx )  are not working. I've tried to change digitmap to xx. without success

Keep in mind, you asked for calls to India from OBi #2 in the form:

00919xxxxxxxxx

whereas from the PHONE Port of OBi #1, you accept them in the form:

0091xxxxxxxxxx


In the beginning:

{200996xxx>(Mvg3):vg3}

didn't work at all.

Then, as a test, you replaced it with:

{200996xxx:vg3}

and

{200996xxx>(xx.):vg3}

Both of these are virtually the same as the first except they don't validate the called number and both worked with French numbers but not Indian numbers.

Then you went back to the original:

{200996xxx>(Mvg3):vg3}

and now it works with French numbers but not Indian numbers.

Indian calls do work when dialed from the PHONE Port of OBi #1 and the failed calls from OBi #2 look identical in the Call History of OBi #1.

None of this makes any sense.


Quote from: Riyas on September 18, 2011, 07:28:14 AM
I still have some issue to call India. Now I am trying to follow this guide :

http://www.obitalk.com/forum/index.php?topic=1103.0

These are my settings in both units:
.
.
.
Speed dial #4 in Obi#2 : 2 **3 0177755xxx

My call goes directly to AA. I don't know what I am doing wrong.

Except for Speed Dial#4 in Obi#2, all settings are same in both units

I don't see anything wrong with what you posted.  I use this configuration in several OBi's as do many other forum members and it works perfectly.


On more than one occasion, I've had OBi's get irrecoverably scrambled internally for no obvious reason and had to return them to factory defaults and reload the very same configuration back into them before they would behave sensibly.  If you don't find an explanation soon, I would recommend resetting BOTH OBi's back to factory defaults and reloading them from scratch.  I would recommend using the configuration from Reply #5 of this thread it's much simpler and easier to debug.  It really should work.