Using OBi Speed Dials w/o Ad Hoc Gateway for 1 stage calling Obi1->Obi2->SP1 sip
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:
Quote
Would 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.
Quote
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!
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}
Navigation
[0] Message Index
[#] Next page
[*] Previous page