Bookmark showing examples of X_InboundCallRoute & other interesting tips:
QBZappy:
How to find info/owner of DID number:
http://www.infodids.com/
How to find info/owner of toll-free DID number:
http://www.800forall.com/
QBZappy:
Interesting thread discussing Rollover lines:
http://www.obitalk.com/forum/index.php?topic=1533.0
Quote from: gobluelou on September 12, 2011, 03:09:41 pm
I couldn't find any info on this searching the forum.
Is there a way to do rollover lines with the obi110? In other words, if you have 4 POTS lines connected to a multiline phone, and you wanted to port those 4 lines to 4 obi110 units (google voice?), can you make it so that if someone calls your main phone number, it bumps to your next number, and then your next number, and then your next number (or in other words, bumps to your next obi, then the next, then the next).
Or perhaps there is a different way to deal with entirely.
QBZappy:
HOWTO: Thwarting SIP Scanners during Set-up
http://www.obitalk.com/forum/index.php?topic=5467.0
Quote from: Shale on March 11, 2013, 08:57:16 am
Note: Things changed for the better about June/July 2013. OBiTalk has been implementing method 4, Oleg method described below, for at least some of the SIP providers by default. If your provider is not one that OBiTalk lists or if you get a SIP scan, or if you have overridden the X_InboundCallRoute so that OBiTalk does not control the field, or if you choose to not use OBiTalk, the information below will still apply. (note #j)
=========The need for the following has been reduced========
An unfortunate thing we all must learn about is how to thwart SIP scanners. It is best to handle this now rather than getting motivated at 4AM by a phantom call with caller ID "1001" or some such. There are four ways to address the SIP scan intruders. For those using OBiTalk to set things up (as I do), each involves using the "OBI Expert Configuration" to change values from the defaults. Methods (pick one only for each SPn Service that is not set up for GV):
0. Disable any unused SPn Service by un-ticking (Voice Services)SPn Service->Enable. This may be unneeded, but it will not hurt for an unused SPn
1. Filter on the length of the caller ID string. This is more complex and seems less effective IMHO. It would seem easy to circumvent by spoofing a real number.
2. Change the (Voice Services)SPn Service->X_UserAgentPort ports for each SPn to a number not in the 506x range. This seems effective based on people's experience, but how long until the scanners broaden their scans?
3. Change the X_AccessList value for each service to permit only the listed IP addresses to be used as a SIP server. If using ObiTalk expert configuration, that path would be :
System Management -> Service Providers-> ISTP Profile n SIP -> X_AccessList
The list is limited in the OBi boxes to 512 characters, and each item in the list can be up to 16 characters long with an average of 14.28 while we are using IPV4 addressing. This would permit maybe 36 addresses to be listed in a comma-separated list. This will be plenty for some SIP suppliers, but not enough for others. I presume Anveo uses anycast IP addresses, because they seem to only use one IP address for each server location. So with Anveo, set the corresponding X_AccessList to
72.9.149.69,67.212.84.21,176.9.39.206
if you want to allow the US, Canadian and German servers. I tested that one. For voip.ms, the expanded 256-character string would be
Code:
174.34.146.162,173.208.83.50,174.137.63.206,174.142.75.171,174.34.146.162,198.144.158.125,199.21.149.36,209.62.1.2,5.77.36.136,64.120.22.242,67.205.74.164,67.205.74.184,67.205.74.187,67.215.241.250,68.233.226.97,69.147.236.82,74.54.54.178,74.63.41.218,78.129.153.20
This was my preferred method if the IPs are known and fit the string. However if OBiTalk performs method 4 for you automatically, then I would now go that way. I would check to see what OBiTalk did for each SPn before implementing new methods:
4. Method 4 , as discovered by Oleg and applied by Mango, is to change the (Voice Services)SPn Service->X_InboundCallRoute: from {ph}, if that is what it currently is, to
{>('Insert your AuthUserName here'):ph}
This method is particularly useful for those using SIP providers that have too many IP addresses to use method #3, although it may become the preferred method for more providers. The AuthUserName can be read from your OBi or ObiTalk expert at
(Voice Services)SPx Service->AuthUserName.
Legend for examples:
6065556789 Sample trusted phone number
17771234567 Sample account name/number for SIP provider. I think they are saying for Callcentric they all start with 1777 followed by 7 more digits. Anveo is also all numbers, but
is a little shorter.
Here are some examples of the Oleg method (please suggest more examples and point out needed fixes):
OBi110 with no trusted caller set up with service 1 being routed to the phone port; (Voice Services)SP1 Service->X_InboundCallRoute:
{ph} [before]
{>17771234567:ph} [after adding protection from SIP scanners]
OBi202 with one trusted caller with service 2 being routed to phone line 2; (Voice Services)SP2 Service->X_InboundCallRoute:
{(x.6065556789):aa},{ph2} [before]
These are both tested to work:
{(x.6065556789):aa},{>17771234567:ph2} [ Tested and works]
{(x.6065556789):aa},{>('17771234567'):ph2} [Permits alphanumerics]
[The single quotes are not needed if the ID is all numbers, but will not hurt]
See note #h below.
Notes:
a. http://www.obitalk.com/forum/index.php?topic=4067.0 discusses the methods including Callcentric IP numbers. http://www.obitalk.com/forum/index.php?topic=5455.msg35330 also discusses the methods including Anveo IP numbers.
b.http://www.obitalk.com/forum/index.php?topic=3544.0 is a feature request asking that OBi firmware to allow specifying blocks of IP numbers into the X_AccessList lists.
c. http://www.obitalk.com/forum/index.php?topic=4873.0 cites #b plus it asks that the OBi have an option to "Reject SIP requests except from registration server".
d. The motivation for the SIP scanners appears to mostly be probing for PBX servers to allow expensive international and premium calls for profit. http://en.wikipedia.org/wiki/Premium-rate_telephone_number
e. I do not know if a port set up for Google Voice could get hit with the phantom phone calls, since it uses a different protocol. Changing X_UserAgentPort will not hurt, and it may be proactive against somebody using that scanning with that protocol in the future.
f. Unused ports should be disabled. One way is to un-check the (Voice Services)SPn Service->Enable box, which is Enabled by default. The OBi202 has 4 SPn ports. Obi100 and OBi110 have 2 SPn ports. You could change your X_AccessList to 0.0.0.0 as a sure method.
g. Search for "SIP scanners" here or elsewhere for more information.
h. Method 4 was posted by Oleg, and Mango recognized the general applicability of this method. See http://www.obitalk.com/forum/index.php?topic=4067.80 to follow the birth and development of this method. I hope to add more examples for other SIP providers, but it is the Callcentric users who cannot use method #3. I got a hub to use Wireshark packet sniffer to monitor communications to my OBi202. Formats are similar to what Oleg saw for Callcentric. Normally you would only use one method for each SP.
j. The implementation of anti-scanner method by OBiTalk was first posted by ianobi on reply 7 of http://www.obitalk.com/forum/index.php?topic=6266.0
QBZappy:
Voip bandwith calculator
http://www.bandcalc.com/
QBZappy:
Home and Remote Configuration Using OBi202s
http://www.obitalk.com/forum/index.php?topic=8003.0
Quote from: ianobi on May 13, 2014, 04:05:54 am
Here’s another version of a master/slave setup which provided a working solution for an OBi owner. The Home OBi202 has two voip numbers; the first dedicated for incoming and outgoing calls on sp1 used by Phone Port 1 only, the second dedicated for incoming and outgoing calls on sp2 used by Phone Port 2 only.
The problem is to replicate the exact same setup at a remote site seventy miles away. The voip provider does not allow multiple registrations on each account.
Remote OBi202 Home OBi202
Ph1
|
Ph1 – sp1 ---- ---------- sp1 ------ voip 1
|------OBiTALK network---------|
Ph2 – sp2 ---- ---------- sp2 ------ voip 2
|
Ph2
Home OBi202 – 500111111
Remote OBi202 – 500222222
Home OBi202
Voice Services > SP1 Service > X_InboundCallRoute:
{ph,pp(ob500222222***1)
Voice Services > SP2 Service > X_InboundCallRoute:
{ph2,pp(ob500222222***2)}
Voice Services > OBiTALK Service > InboundCallRoute:
{(500222222)>(<**1:>(xx.)):sp1},{(500222222)>(<**2:>(xx.)):sp2},{500222222:aa},{ph}
Remote OBi202
Set up “fake” SIP providers on sp1 and sp2 (see below). Configure Phone 1 for outgoing and incoming on sp1 only. Configure Phone 2 for outgoing and incoming on sp2 only.
Physical Interfaces > PHONE Port 1 > OutboundCallRoute:
Find this rule {(Mpli):pli} – it’s normally the last rule – delete it and replace with {(<ob500111111***1>(Mpli)):pp}
Physical Interfaces > PHONE Port 2 > OutboundCallRoute:
Find this rule {(Mpli):pli} – it’s normally the last rule – delete it and replace with {(<ob500111111***2>(Mpli)):pp}
Voice Services > OBiTALK Service > InboundCallRoute:
{500111111>(**1):ph},{500111111>(**2):ph2},{ph}
Notes
1. For clarity I have omitted any references to the OBiON 290xxxxxx number. Also I have not included the Oleg Method.
2. The final rule in Voice Services > OBiTALK Service > InboundCallRoute can be as shown {ph} or {ph2} or {ph,ph2} or omitted, depending on how you wish to route general calls on the OBiTALK network to be routed in each OBi202.
3. By setting up suitable speed dials, any Home or Remote OBi Phone Port can call any other Home or Remote OBi Phone Port. This also allows for call transfer between any of the four Phone Ports and three-way calls to be set up.
4. This setup effectively gives each voip line two endpoints. Most voip providers allow two sessions (calls) on each line. This allows a call from the Remote OBi202 from Phone Port 1 to take place at the same times as an ongoing call taking place from Phone Port 1 of the Home OBi. The possible downside of this is that if a call is ongoing at either site an incoming call on the same line will automatically be routed to the other OBi202. This may be good or bad depending on what you want this setup to do. This behaviour can be controlled by changing the “MaxSessions” setting.
5. The Remote OBi202 can be anywhere in the world. For this reason I have not suggested how to provide 911 service to it. If required, then 911 calls can be routed from the Remote OBi202 through the Home OBi202.
Example “Fake” SIP provider for sp1:
Service Providers -> ITSP Profile A -> SIP -> ProxyServer : 127.0.0.1
Voice Services -> SP1 Service -> Enable : (checked)
Voice Services -> SP1 Service -> AuthUserName : 1234 (any numbers/letters)
Voice Services -> SP1 Service -> X_RegisterEnable : (unchecked)
Voice Services -> SP1 Service -> X_ServProvProfile : A
Voice Services -> SP1 Service -> CallerIDName : Whatever
Navigation
[0] Message Index
[*] Previous page