Using the described setup for scenario 2 in ianobi's post http://www.obitalk.com/forum/index.php?topic=6947.msg43848#msg43848 (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.
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
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.
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.
@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?
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.
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).
Did you try dialing 8*3333
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?
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.
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.
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.
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.
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.
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}
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?
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.
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.]
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}
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
I didn't find SIP ALG. let me explain more. On both Obis I set GV on SP1. when obi1 calls obi2 through GV they connect to each other perfectly.Do you think still the network has a problem?
Quote from: Hadi on July 22, 2015, 06:06:17 PM
I didn't find SIP ALG. let me explain more. On both Obis I set GV on SP1. when obi1 calls obi2 through GV they connect to each other perfectly.Do you think still the network has a problem?
Which router do you have? The ALG option may also be called something along the lines of SIP passthru.
Quote from: azrobert on July 13, 2015, 06:13:08 AM
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}
More oddness - this
was working, but longer seems to. The fork is shown in the Obi1 call log, but never shows up on the Obi2, unless the
*0 is removed. ???
Wondering if other stuff in my Obi1 inbound routes was causing issues, I temporarily replaced the SP2 (callcentric) inbound with just
pp(200222222*0) to see what response I'd get when calling in to SP2 - as long as the
*0 is present, the reponse is an announcement that
'The Person you are trying to reach is currently unavailable, please try again later. Message 1004' - which I assume is an Obihai announcement. If the *0 is removed the call forks thru to the Obi2 (but I obviously can't control whether it goes to the AA/phone anymore).
The message you are receiving doesn't sound like it's coming from the OBi. It sounds like a Callcentric message. I called a Callcentric extension that that wasn't signed in and the first part of the message I received was exactly like what you posted. Mine went to VM, so the 2nd half of the message was different. What is defined on OBi2 SP1?
Try forking the call without *0 and look at the call history on OBi2. The Peer Number should be 500111111. What is the Peer Number? If it is 500111111 it should be routed to the AA, but it's routed to the phone port. This is strange.
Quote from: azrobert on July 29, 2015, 02:17:28 PM
The message you are receiving doesn't sound like it's coming from the OBi. It sounds like a Callcentric message. I called a Callcentric extension that that wasn't signed in and the first part of the message I received was exactly like what you posted. Mine went to VM, so the 2nd half of the message was different. What is defined on OBi2 SP1?
You're right, that is a callcentric msg - on Obi1, SP2 is setup for callcentric. On Obi2, SP1 is setup for sip2sip, but it's ObiTALK inbound directs anything from Obi1 (without the *0) to it's AA, so SP1 never comes into play for this.
When I change the SP2 inbound on Obi1 to just
pp(200222222*0), in addition to the callcentric msg 1004, the Obi call log shows End Call (404 Not Found) - when the inbound is just
pp(200222222), the call is directed to Obi2 as expected. When
pp(200222222*0) is included as part of a fork, the fork is shown in the call log, but silently fails for that portion (other fork recipients
do get the call directed to them). It looks like Obi1 cannot properly parse that Obi number when *0 is present.
QuoteTry forking the call without *0 and look at the call history on OBi2. The Peer Number should be 500111111. What is the Peer Number? If it is 500111111 it should be routed to the AA, but it's routed to the phone port. This is strange.
The Peer Number on these calls always reflects the caller-ID number of the originating caller (ie: if I initiate an inbound call from my callcentric extension 101, then that is what is shown as Peer Number on Obi2 after the fork from Obi1). Since you really
do want the originating caller-ID number to be shown, I assumed this to be correct behavior. 500111111 is only shown as Peer Number when the call to Obi2 is directly initiated from Obi1 via ObiTALK.