News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Using OBi Speed Dials w/o Ad Hoc Gateway for 1 stage calling Obi1->Obi2->SP1 sip

Started by limey, July 10, 2015, 06:37:22 PM

Previous topic - Next topic

limey

Using the described setup for scenario 2 in ianobi's post http://www.obitalk.com/forum/index.php?topic=6947.msg43848#msg43848, I've got an Obi110 with speedials setup to go via ObiTalk to an Obi100 and then go outbound via sip2sip on SP1.

Using ianobi's examples as a starting point to illustrate, with Obi1 as 500111111 and Obi2 as 200222222 & the Voice Services > OBiTALK Service > InboundCallRoute on Obi2 set to: {500111111>(xx.):sp1},{500111111:aa},{ph}

Speed dial 8 –   Sister:   pp(ob200222222)
This works fine - call is initiated from Obi1 & gets the AA on Obi2, from where outgoing SP1 calls can be made manually.

Speed dial 10 -   Parents:   pp(ob200222222*3333)
This fails, producing a 404 Not Found error in Obi1's call history, where the outgoing OBiTALK1 peer number resolves to ob200222222*3333. The call doesn't appear in Obi2's call history, so the call doesn't appear to make it out from Obi1, when *3333 is included on the speeddial. (3333 is a sip2sip test number.)

Any ideas what might be wrong here? I'm suspecting a digimap issue, but ianobi's post didn't mention any further changes been necessary for the 2nd scenario beyond the OBiTALK InboundCallRoute on Obi2.

azrobert

I don't see anything wrong with your configuration. The 404 error on the OBiTalk network usually means the OBi number wasn't found, but the same OBi number without data was found.

You said in another thread
QuoteManually upgrading to the current fw build, then updating the GV settings via the ObitTalk portal is the way I will eventually go, but I might try out build 2824 first, just to see if it connects as azrobert reports.

I assume this means you are still on build 2711. Maybe this is a FW problem.
You can try 2 other formats:
Speed Dial 10:
pp(200222222*3333)
The "ob" is optional
or
pp(8*3333)
8 points to speed dial#8

limey

Quote from: azrobert on July 10, 2015, 09:50:23 PMI assume this means you are still on build 2711. Maybe this is a FW problem.
You can try 2 other formats:
Speed Dial 10:
pp(200222222*3333)
The "ob" is optional
or
pp(8*3333)
8 points to speed dial#8

pp(200222222*3333) also fails with the 404 error, but...

pp(8*3333) works correctly.  ;D

Thanks for that azrobert!

Both Obis are currently still on 2711, so I did consider firmware differences might be at play, but didn't find any reports of such. Still, it's odd that the former fails, but the latter works. Since I wasn't aware of either alternative, I've also learned something.

ianobi

I thought I would make a few test calls on this one to check that Obihai have not changed how their servers route calls. In my case OBi1 is an OBi110 and OBi2 is an OBi1032 with sip2sip on sp2. Coincidentally, my OBi1032 happens to really be speed dial slot 8.

I set up speed dials and dialled them from the OBi110 using the formats:
pp(ob610222222*3333)
pp(610222222*3333)
pp(8*3333)

All three tests worked fine and resulted in the James Bond theme being received loud and clear. It seems that single stage dialling from one OBi device through another OBi device still works the way it always did.

It seems that we are left with the mystery of why only the pp(8*3333) format works for limey. It seems odd as it must require an extra look-up in the Obihai servers to convert the "8" into the actual number for speed dial slot 8 for the calling device before routing the call. The other formats simply require to be routed by the servers.


limey

@ianobi - the only things I can think of are that it's related to the 2711 fw build, or that I've somehow introduced something funky into the Obi110 config along the way (I'm fairly conservative about changing stuff, but it remains a possibility).

Whilst pp(8*3333) remains the only variation that currently dials thru to Mr Bond, I must correct myself slightly on the pp(200222222*3333) option - this actually fails with a fast-busy signal rather than a 404 error (sorry - brain fade whilst typing). In the Obi110 log, it reports the outgoing OBiTALK1 peer number resolving to 200222222*3333 & shows a New Call, but gets no further. It doesn't make it as far the receiving Obi100's call log. Maybe a further clue as to what might be happening?

Would pp(8*3333) actually require a server lookup? I thought that the speed-dials were locally stored on the Obi?

azrobert

I don't know about FW 2711, but my OBi110 at FW 2824 is already setup to route calls with data from the Phone Port to another OBi.
The 1st rule in my Phone Port DigitMap is: [1-9]x?*(Mpli)
(Mpli) points to the primary ITSP DigitMap
If you haven't removed rule "xx.", the above rule will verify a dialed number like 8*3333
The 1st rule in my Phone Port outbound call route is: {([1-9]x?*(Mpli)):pp}
This will route 8*3333 to the OBiTalk network.
If 2711 is missing these rules, just add them.
Make sure the rule is placed after the beginning parenthesis in the DigitMap.
Now dial 8*3333

Edit:
The above is FYI and not a reply to anything posted.

limey

Quote from: azrobert on July 11, 2015, 07:51:12 AM
The 1st rule in my Phone Port DigitMap is: [1-9]x?*(Mpli)
(Mpli) points to the primary ITSP DigitMap
If you haven't removed rule "xx.", the above rule will verify a dialed number like 8*3333
The 1st rule in my Phone Port outbound call route is: {([1-9]x?*(Mpli)):pp}
The above match the settings on my Obi110 (actually, both the Phone digitmap & outbound call route are still at their default values).

azrobert


limey

Quote from: azrobert on July 11, 2015, 08:19:22 AM
Did you try dialing 8*3333
Just did - it fails with error 503 (503 Service Unavailable in call history)

Does that shed any further light?

azrobert

Does the call history show 8*3333 being routed to OBiTalk?

I think you have a FW problem, but it's your choice to upgrade or not.

limey

Quote from: azrobert on July 11, 2015, 08:40:25 AM
Does the call history show 8*3333 being routed to OBiTalk?

I think you have a FW problem, but it's your choice to upgrade or not.
Yes, the call went to OBiTALK1.

FW does seem the most likely culprit. I'll be upgrading the firmware sooner than later for GV, so I'll report back if doing so has any effect on this behavior - in the meantime, pp(8*3333) works effectively enough.

ianobi

QuoteWould pp(8*3333) actually require a server lookup? I thought that the speed-dials were locally stored on the Obi?

OBiTALK uses a proprietary protocol, so cannot be fully analysed even with a protocol analyser such as Wireshark. However, the outgoing OBi device shows 8*3333 going outbound on OBiTALK 1, so I'm guessing that the translation to an actual OBi number takes place in the Obihai servers, but there's no way to be 100% sure.

This morning (Sunday) all three formats I tested above are failing. I guess it's one of the frequent weekend glitches the Obihai servers seem to have. I'll test again on Monday when someone comes into work and presses the "reset" button!

My preferred rules relevant to this subject are:

Physical Interfaces > PHONE Port > DigitMap:
([1-9]x?*@@.| other rules here

Physical Interfaces > PHONE Port > OutboundCallRoute:
{([1-9]x?*@@.):pp}, other rules here

These provide as much flexibility as possible for sending routing information etc. Both rules were first suggested by RonR.



limey

Quote from: ianobi on July 12, 2015, 04:43:29 AM
OBiTALK uses a proprietary protocol, so cannot be fully analysed even with a protocol analyser such as Wireshark. However, the outgoing OBi device shows 8*3333 going outbound on OBiTALK 1, so I'm guessing that the translation to an actual OBi number takes place in the Obihai servers, but there's no way to be 100% sure.
It all depends on whether the outbound peer number is shown after all transformations & lookups are complete.

QuoteThis morning (Sunday) all three formats I tested above are failing. I guess it's one of the frequent weekend glitches the Obihai servers seem to have. I'll test again on Monday when someone comes into work and presses the "reset" button!
Sip2sip might be having some issues as calling 3333 directly from Obi2 fails with a 500 Internal server error (as does single stage dialing from Obi1).

However, I've noticed some other weirdness today - Obi1 has long been setup to fork all incoming calls into it's Line port to Obi2 (and an Obi softphone) via OBiTALK. Usually, these forked calls ring on Obi2's Phone port, with only calls that originated from Obi1's OBiTALK endpoint getting the Obi2's AA - however, today I noticed that any incoming call to the Obi1 Line port is getting Obi2's AA. The OBiTALK InboundCallRoute is unchanged from the 1st post, so I've no idea why calls with an incoming peer number other than 500111111 are getting the AA. For now, I'll either remove the call fork from Obi1, or remove 500111111 from the OBiTALK InboundCallRoute on Obi2, but I need to figure out why this has started happening.

ianobi

My apologies to Obihai, as far as I can tell their servers are working just fine. You are correct - it's sip2sip that's having problems just now. I set up the same speed dial tests using a Sipgate test number (10000) and repeated the tests:

I set up speed dials and dialled them from the OBi110 (OBi1) using the formats:
pp(ob610222222*10000)
pp(610222222*10000)
pp(8*10000)

All three tests successfully completed the test calls using the Sipgate service on OBi2.

Also, I tried manually dialling 8*10000 from OBi1 and that works fine too.



azrobert

It's working correctly.
Any call from OBi1 using OBiTalk will have a CallerID=500111111
If the call is sent to OBi2 phone port, the original CallerID will magically be passed.
Did you upgrade FW?

Try this:
OBi1 Line inbound route
ph,pp(200222222*0),pp(290xxxxxx)
OBi2 OBiTalk inbound route
{500111111>0:ph},{500111111>(xx.):sp1},{500111111:aa},{ph}

limey

Quote from: azrobert on July 13, 2015, 06:13:08 AM
It's working correctly.
Any call from OBi1 using OBiTalk will have a CallerID=500111111
If the call is sent to OBi2 phone port, the original CallerID will magically be passed.
Could have sworn it wasn't getting the AA before, but it's possible I missed the effects after making changes.

QuoteDid you upgrade FW?
Not yet - making sure I know where I am with the current config first.

QuoteTry this:
OBi1 Line inbound route
ph,pp(200222222*0),pp(290xxxxxx)
What does the *0 part of the Obi1 Line inbound route do?

Quote
OBi2 OBiTalk inbound route
{500111111>0:ph},{500111111>(xx.):sp1},{500111111:aa},{ph}
Same question for >0 for the Obi2's OBiTalk inbound route?

azrobert

I assumed you have a speed dial defined as pp(200222222) and want it routed to the AA. This call will not have any data, so it will not match rule {500111111>(xx.):sp1}. Rule {500111111:aa} will match it because it's only checking for the OBi number and will send the call to the AA.

*0 will pass zero as data, the same as *3333 will pass 3333 as data. You can use any character string as long as it's unique.
{500111111>0:ph} will check for zero and upon a match will send the call to the phone port.

limey

Quote from: azrobert on July 14, 2015, 06:12:45 AM
I assumed you have a speed dial defined as pp(200222222) and want it routed to the AA. This call will not have any data, so it will not match rule {500111111>(xx.):sp1}. Rule {500111111:aa} will match it because it's only checking for the OBi number and will send the call to the AA.

*0 will pass zero as data, the same as *3333 will pass 3333 as data. You can use any character string as long as it's unique.
{500111111>0:ph} will check for zero and upon a match will send the call to the phone port.

That's quite clever, if I understand it right...

So, all incoming calls to Obi1's Line port, get 0 tacked on as data & are then forked to Obi2 via ObiTALK.

Then, the {500111111>0:ph} in Obi2's ObiTALK inbound route matches that 0 data & hands that call to it's Phone port, with order precedence preventing any matches from the remaining sp1/aa/ph parts of the ObiTALK inbound route.

As long as the value tacked on as data never corresponds to anything that you'd ever want to call on the default outbound Obi2 port via single stage dialing, then all is good.

Nifty.

[Edit: Just tried your suggestions & they seem to do the trick - thanks.]

Hadi

I have an another problem. I can not even connect to obi2 from obi1. I have two OBi110s at FW2824 and obi1 can  connect to obi2 just 1 second ( I just hear welcome to) and then disconnected. When I call Obi2 from Obion, I don't have any problem. Can you solve my problem too?
on obi2:
OBi2 OBiTalk inbound route:
{(290xxxxxx|200xxxxxx):AA}



azrobert

This sounds like a network problem. Check the local and remote routers for SIP ALG. If it's enabled, disable it. Some routers don't have this option.

The following has nothing to do with your problem.
In Voice Services -> Auto Attendant
Set these parms

Welcome: &pause()
MenuTitle: &pause()

Now you don't hear these prompts when routed to the AA