News:

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

Main Menu

Setting up an Obi 202 + Obiline in the UK (Draft)

Started by Mouse, July 10, 2015, 04:26:34 AM

Previous topic - Next topic

Mouse

#40
Thanks I have set 400 Ring Delay and disconnect tone of 400@-30,400@-30; 2(3/0/1+2)

Working OK so far, will report back later.

I have also found on my long line that a line impedance of 320 + 1050||230 seem to help the echo.

Just to note that in general when experimenting with different impedances, you may have to increase the TX or RX gain, or DTMF may not be recognised. I think some impedances have a higher power loss rate at DTF frequencies than others.

(There seems to be little margin in the TX gain of 0db!)

Mouse

Comparing echo on 110 and 202 I happened to notice that the latest 110 file did not set phone port ringer parameters. It did set ring delay though.

Could be there's a problem with the restore function......

110 is significantly better than 202 re echo BTW on my line.

202 still working OK with new disconnect settings .....

Mouse

Applied disconnect tone settings to 110: 400@-30,400@-30; 2(3/0/1+2)

Mouse

Now have both 110 and 202 working simultaneously  ;D

Both have outboud SIP and PSTN

Both receiving PSTN calls, though probably only one receiving SIP calls (firewall port forward rule)

Mouse

I am just wondering whether the best way to solve the PSTN echo is to use the 220+110 and send back the obiline.

I'm guessing I can fork our main phone system to both Obis.

Then on the 110 I could set the line socket to send through to PH as usual. Phone socket could default to a SIP service, as I am happy to use SIP outbound always.

On the 202, there would be no line connection, it could use any SIP outbound and receive inbound SIP.

More elegantly I could use the 202 as the front end for all outbounds, referring using Obitalk requests for outbound PSTN connections to a 110 running in the 202s network. Inbound SIP could then go to either depending on the SIP service (using server IP-based PF rules). Inbound PSTN would go to the 110. (Port forward rules would be fun  ;D)

What do you think?

ianobi

The OBi110 and the OBi202 can work as one combined device with each having access to the others' services. I would not put the OBi110 in the OBi202's network. So long as both devices are in the same router's subnet and both have static subnet ip addresses.

This gives you six spX services and a Line Port. You need to give each spX a unique UserAgentPort and it helps to use unique RTP ports for each service. With this setup calls can be routed to and from any spX or Line Port. All of the routing is done internally within the router subnet.

There are several different ways of routing the calls between the two OBi devices, but I like to dedicate a whole spX on each device to be the two ends of a link between them. However, if there is not a spare spX on each device, then Voice Gateways can be used. The former method makes passing CName and CallerID easy and makes DigitMaps a little more simple.

Comments on the forum would suggest that the OBi110 is a much better link to PSTN than the OBiLINE. I have two OBi110s and have never experienced any echo. I have not tried an OBiLINE, so I'm just judging by the comments of others regarding that.

Mouse

Quote from: ianobi on July 21, 2015, 09:21:09 AM
The OBi110 and the OBi202 can work as one combined device with each having access to the others' services. I would not put the OBi110 in the OBi202's network. So long as both devices are in the same router's subnet and both have static subnet ip addresses.

This gives you six spX services and a Line Port. You need to give each spX a unique UserAgentPort and it helps to use unique RTP ports for each service. With this setup calls can be routed to and from any spX or Line Port. All of the routing is done internally within the router subnet.

There are several different ways of routing the calls between the two OBi devices, but I like to dedicate a whole spX on each device to be the two ends of a link between them. However, if there is not a spare spX on each device, then Voice Gateways can be used. The former method makes passing CName and CallerID easy and makes DigitMaps a little more simple.

Comments on the forum would suggest that the OBi110 is a much better link to PSTN than the OBiLINE. I have two OBi110s and have never experienced any echo. I have not tried an OBiLINE, so I'm just judging by the comments of others regarding that.

Thanks that's very interesting. I have not dug deep enough to know what a user agent port is, and how it could be used, could you maybe explain? (Is it maybe a SIP signalling port?)

Do they dial each other using the Obi number?

ianobi

QuoteThanks that's very interesting. I have not dug deep enough to know what a user agent port is, and how it could be used, could you maybe explain? (Is it maybe a SIP signalling port?)

Yes, it is the SIP signalling port. OBi terminology is a bit quirky!


QuoteDo they dial each other using the Obi number?

This is a big question! No, all routing is internal within your router subnet. The DigitMaps would need working out, but you might do something like this:

**1 SP1 OBi202
**2 SP2 OBi202
**3 SP3 OBi202
**4 SP4 OBi202
**6 SP1 OBi110
**7 SP2 OBI110
**8 Line Port OBi110

I've not bothered with OBiTALK for now and you might lose two of the above spXs if they form the link between the two devices.

You have three Phone Ports and with the right DigitMaps say you dial **201234567891 from any of the three Phone Ports, then the number 01234567891 would be routed out of the SIP service on SP2 of the OBi202.

For routing incoming calls it's useful for each phone port to have a number say:
Phone Port 1 OBi202 - 601
Phone Port 2 OBi202 - 602
Phone Port 1 OBi110 - 603

Incoming calls from any service can then be forwarded to any Phone Port(s) which will be identified by its 6xx number. The number will be automatically added by the OBi devices for call routing purposes, the caller just dials in as normal. If needed any of the three ports can call the other ports using it's 6xx number - useful for call transfers etc.

It would be a "project", but similar setups have been done before. I have something similar here using an OBi110 and an OBi1032.



Mouse

Thanks very much, not sure I am quite understanding. Sorry to be dumb.

How would I specify and where would I put the rule:

"Inbound on Line 1 port of Obi 110 goes out to telephone attached to Ph2 port of Obi 202"

(That would be the most important rule for me .....)

Kind regards

Mike

ianobi

If the direct link between the two devices had been set up using sp2 in the OBi110 and sp4 in the OBi202, then it could be as simple as this:

OBi110 Physical Interfaces > LINE Port > InboundCallRoute:
{ph,sp2(602)}

All calls coming into the Line Port of OBi110 ring the attached phone of the OBi110 and send digits "602" out via sp2 (anything sent to OBi110 sp2 arrives at OBi202 sp4 via the link). Remove "ph" if it is not required to ring the OBi110 phone.

OBi202 Voice Services > SP4 Service > X_InboundCallRoute:
{>602:ph2}

All calls inbound on sp4 with digits "602" ring Phone Port 2.

The above example is simplified and omits some security measures and other rules to route calls from other inputs to ph2, but I hope that you get the idea.

The link between OBi110 sp2 and OBi202 sp4 would direct all calls between the two using each others' fixed local ip address / SIP port. Too much detail for this example.


An incoming call to any OBi device can be directed to any ip address / port. For instance if I only have an OBi110 and want to direct incoming calls at the line port to a SIP softphone on a PC with address 192.168.10.45:5060, then this would be the rule:

OBi110 Physical Interfaces > LINE Port > InboundCallRoute:
{ph,sp2(1@192.168.10.45:5060)}

This would ring the OBi110 phone and "fork" the call using OBi110 sp2 to the softphone. Whichever answers first takes the call. The "1" in sp2(1@192.168.10.45:5060) can be anything, the softphone does not use it, but it's needed to comply with the required format.



Mouse

OK I got it - roughly. I did not know you could just fire SIP at an IP and a service.

For simplicity I have put

*Obi 110*
Inbound call route PH,VG8
VG8 ~ Number: ph1(192.168.1.23:5068)
All other VG8 fields blank

*Obi202*
Nothing!

The VG does not seem to need the '1@' according to the manual. I'll try this tomorrow

ianobi

A VG uses the SIP functions of an spX to work, so in this case it is redundant - much easier simply to use the spX. The spX simply has to be enabled and configured for SIP, which is the default situation. The same spX can be used for other services as well, so it is not dedicated to this one use. I suggest:

OBi110 Physical Interfaces > LINE Port > InboundCallRoute:
{ph,sp2(192.168.1.23:5068)}

Where 192.168.1.23:5068 is the ip address and UserAgentPort of one of the spX services of the OBi202. Its InboundCallRoute needs to be able to accept the call - the default "ph1,ph2" will do fine.



ianobi

I may have overlooked the obvious here! In the above example the spX has to be "in use". If OBi110 sp2 is spare, then set it up as a "fake" provider:

Service Providers -> ITSP Profile B -> SIP -> ProxyServer : 127.0.0.1
Service Providers -> ITSP Profile B -> SIP -> X_SpoofCallerID : checked

Voice Services -> SP2 Service -> Enable : (checked)
Voice Services -> SP2 Service -> AuthUserName : (any letters or numbers but not blank)
Voice Services -> SP2 Service -> X_RegisterEnable : (unchecked)
Voice Services -> SP2 Service -> X_ServProvProfile : B
Voice Services -> SP2 Service -> CallerIDName : Whatever

Mouse

Quote from: ianobi on July 22, 2015, 01:31:43 AM
A VG uses the SIP functions of an spX to work, so in this case it is redundant - much easier simply to use the spX. The spX simply has to be enabled and configured for SIP, which is the default situation. The same spX can be used for other services as well, so it is not dedicated to this one use. I suggest:

OBi110 Physical Interfaces > LINE Port > InboundCallRoute:
{ph,sp2(192.168.1.23:5068)}

Where 192.168.1.23:5068 is the ip address and UserAgentPort of one of the spX services of the OBi202. Its InboundCallRoute needs to be able to accept the call - the default "ph1,ph2" will do fine.




That makes sense to me, thanks very much for all your help. I will try that this evening.

Mouse

Quote from: ianobi on July 22, 2015, 01:45:01 AM
I may have overlooked the obvious here! In the above example the spX has to be "in use". If OBi110 sp2 is spare, then set it up as a "fake" provider:

Service Providers -> ITSP Profile B -> SIP -> ProxyServer : 127.0.0.1
Service Providers -> ITSP Profile B -> SIP -> X_SpoofCallerID : checked

Voice Services -> SP2 Service -> Enable : (checked)
Voice Services -> SP2 Service -> AuthUserName : (any letters or numbers but not blank)
Voice Services -> SP2 Service -> X_RegisterEnable : (unchecked)
Voice Services -> SP2 Service -> X_ServProvProfile : B
Voice Services -> SP2 Service -> CallerIDName : Whatever


If I have understood correctly to implement my example you mean SPx of the Obi 202.

So I need to set up a fake service on the OBI 202 to listen on port 5068 for incoming from the Obi 110. I suppose from what you say it could be an existing service if I had one listening on 5068 but I do not - but that would risk tying up the service when it was needed for other things.

Thanks very much again. I would have had trouble working out how to set up a fake service.

Kind regards

Mike

ianobi

For this to work:

OBi110 Physical Interfaces > LINE Port > InboundCallRoute:
{ph,sp2(192.168.1.23:5068)}

You are using sp2 in the OBi110 to send the call to the address/port within the parentheses. So if OBi110 sp2 is not already in use with a voip service provider, then it needs to be set up as a "fake" service provider as detailed above.

In the OBi202 the default UserAgentPorts are sp1 5060; sp2 5061; sp3 5062; sp4 5063. Assuming that the OBi202 ip address is 192.168.1.23, then you can "aim" the call at any one of them assuming that the InboundCallRoute is at default "ph,ph2" and the service is enabled:
Voice Services -> SPx Service -> Enable : (checked)
Both phone ports will ring. This does not stop the spX service in the OBi202 being used for other
things.

So if you are aiming at say OBi202 sp3, then in the OBi110 the rule would be:
OBi110 Physical Interfaces > LINE Port > InboundCallRoute:
{ph,sp2(192.168.1.23:5062)}

This means it's really easy to aim SIP calls at any OBi spX. This can be a bad thing! After you get the above example working I'll pass on some advice regarding security to stop the dreaded sip scanners calling you every five minutes in the middle of the night. However, let's keep it simple for now.


Mouse

Quote from: ianobi on July 22, 2015, 06:41:10 AM
For this to work:

OBi110 Physical Interfaces > LINE Port > InboundCallRoute:
{ph,sp2(192.168.1.23:5068)}

You are using sp2 in the OBi110 to send the call to the address/port within the parentheses. So if OBi110 sp2 is not already in use with a voip service provider, then it needs to be set up as a "fake" service provider as detailed above.

In the OBi202 the default UserAgentPorts are sp1 5060; sp2 5061; sp3 5062; sp4 5063. Assuming that the OBi202 ip address is 192.168.1.23, then you can "aim" the call at any one of them assuming that the InboundCallRoute is at default "ph,ph2" and the service is enabled:
Voice Services -> SPx Service -> Enable : (checked)
Both phone ports will ring. This does not stop the spX service in the OBi202 being used for other
things.

So if you are aiming at say OBi202 sp3, then in the OBi110 the rule would be:
OBi110 Physical Interfaces > LINE Port > InboundCallRoute:
{ph,sp2(192.168.1.23:5062)}

This means it's really easy to aim SIP calls at any OBi spX. This can be a bad thing! After you get the above example working I'll pass on some advice regarding security to stop the dreaded sip scanners calling you every five minutes in the middle of the night. However, let's keep it simple for now

Thanks very much I had misunderstood the 'sp2'. I thought it referred to the service on the remote machine. The admin manual sections on VGs, which have a somewhat similar syntax, seem to me very misleading in this respect.

I think I can have a go at this now. Probably tomorrow if my wife is out - ringing of the phones during testing drives her mad!

(I'd intend to deal with the scanners by ensuring the router port forward rules refer to the source server IP - will that suffice?)

Kind regards

Mike

drgeoff

Quote from: Mouse on July 22, 2015, 02:15:07 PM(I'd intend to deal with the scanners by ensuring the router port forward rules refer to the source server IP - will that suffice?)
A typical home router doesn't have that functionality.

ianobi

#58
Firstly, get the simple rule detailed above working!

Next, we need to go into OBiNerd mode regarding security and InboundCallRoutes.

A slightly simplified InboundCallRoute rule looks like this:

caller > callee: terminal

In the rule detailed in our previous posts we are only using "terminal" i.e. "ph,ph2" meaning that any call that makes it to the correct ip address/port will ring Phone Ports 1 and 2. To be more selective let's say that certain digits need to arrive to call Phone Port 2. We cannot control the "caller" as we checked SpoofCallerID so that the incoming CallerID is passed along from the OBi110 Line Port to the OBi202 Phone Port 2 . So we first change the call being sent from the OBi110:

OBi110 Physical Interfaces > LINE Port > InboundCallRoute:
{ph,sp2(602@192.168.1.23:5062)}

This means that we are now sending digits 602 to the ip address of the OBi202 and selecting sp3's UserAgentPort. At the OBi202 incoming:

Voice Services > SP3 Service > X_InboundCallRoute:
{>602:ph2}

Where 602 is the "callee". The ">" is required to show that the "caller" is left blank in this rule and so allows any CallerID. Of course 602 could be replaced with a more complex set of digits for added security, so long as it matches in the outgoing OBi110 rule and the incoming OBi202 rule.

Now it is almost impossible for anyone to get a call into your OBi202 sp3, except by dialling in via your PSTN number.

Lots more regarding security here:

http://www.obitalk.com/forum/index.php?topic=5467.msg35387#msg35387

I'm guessing that you have more than enough to think about for now! Let us know how you get on.

Edit: Changes made to reflect that CallerID cannot be used for security if it needs to be passed onto Obi202 Phone Port 2.

NoelB

Quote from: ianobi on July 22, 2015, 06:41:10 AM

So if you are aiming at say OBi202 sp3, then in the OBi110 the rule would be:
OBi110 Physical Interfaces > LINE Port > InboundCallRoute:
{ph,sp2(192.168.1.23:5062)}


Taking this a little bit further I have an obi202 and an obi110 working independently but rather than call out from the 202 line port I would like to direct the call to the 110 and use its line port to call out.
So would this work. In the 202 phone OBCR I have ,{(Mli):li}, change this to ,{(Mli):sp2(192.168.1.103:5061)} where this is the ip addr of the 110 and sp2 of obi110 is already configured with a sip voip provider.
Now comes my dilemma as to what to use as the incoming call route on 110 sp2 first to send the dialled number to the obi110 line port and secondly not to obstruct any call coming in on sp2 from the voip provider coming in to the phone port. Maybe I have to remove everything and set it up with a dummy and drop the voip provider on sp2.