31 May
2016
31 May
'16
5:34 a.m.
The fact is that, actually the repeater is networked
to the EchoLink
server and this can be obtained ONLY by using the commercial
IP number, i.e. IP address 79.47.199.234.
Look at our repeaters, e.g. PI2NOS
It is registered on the Echolink system using its own address 44.137.72.130
(pi2nos.ampr.org).
Therefore this problem does not occur here.
the incoming IP results 44.137.41.97; so I understand
that the
internet server act as the real gateway in a similar way as our
ampr.org gateways. It function very OK!
Yes, for "normal traffic" it works OK. But not for Echolink.
This is because Echolink has a directory server that registers your repeater
by IP address, and this address does not match the actual address.
When you get connected by someone from plain internet, it works OK because the route
back is through the same NAT router, where you have defined port forwarding for the
5198 and 5199 ports, and the users sees the same translated address as the Echolink
system
registered.
However, when I connect from my address 44.137.41.97, the repeater or another part of
the system thinks it is being clever and routes the traffic through a IPIP tunnel,
the address does not get translated, and the connection fails.
The quick way to solve it is to give your repeater some RFC1918 address (10.x.x.x,
192.168.x.x)
so its traffic is always forced through the NAT router. Alternatively, you can setup
some
policy routing so the Echolink traffic is always sent to the NAT router, not routed
directly.
Then you can still use AMPRnet on the same computer for other things.
The way we solved it here is by applying for BGP routing of our subnet, so our net-44
traffic
is routed directly on internet and it is no problem to run an Echolink repeater on it.
(the subject of this thread: will routing through UCSD cause problems with VoIP. yes it
will,
but we don't route through UCSD so we don't have that problem)
Rob
31 May
31 May
12:11 p.m.
New subject: AMPRNET katency in VOIP connections ?
Very TNX Rob. I conceptually understood the possible scenarios
and I'll seek the method to force the 192.168.x.x or the 10.x.x.x
towards the repeater...
However it seems to me that the BGP routing of the 44.x.x.x IPs
remains the best and clean solution for any kinda problems.
So, coming back to the original item on the subject: if, at least,
my main server IPs 44.134.32.240 and 44.134.32.233 were
full published and routed over the internet by UCSD any problems
here should magically solved :)
73, gus
On 05/31/2016 11:34 AM, Rob Janssen wrote:
(Please trim inclusions from previous messages)
_______________________________________________
The fact is that, actually the repeater is
networked to the EchoLink
server and this can be obtained ONLY by using the commercial
IP number, i.e. IP address 79.47.199.234.
Look at our repeaters, e.g. PI2NOS
It is registered on the Echolink system using its own address
44.137.72.130 (pi2nos.ampr.org).
Therefore this problem does not occur here.
the incoming IP results 44.137.41.97; so I
understand that the
internet server act as the real gateway in a similar way as our
ampr.org gateways. It function very OK!
Yes, for "normal traffic" it works OK. But not for Echolink.
This is because Echolink has a directory server that registers your
repeater
by IP address, and this address does not match the actual address.
When you get connected by someone from plain internet, it works OK
because the route
back is through the same NAT router, where you have defined port
forwarding for the
5198 and 5199 ports, and the users sees the same translated address as
the Echolink system
registered.
However, when I connect from my address 44.137.41.97, the repeater or
another part of
the system thinks it is being clever and routes the traffic through a
IPIP tunnel,
the address does not get translated, and the connection fails.
The quick way to solve it is to give your repeater some RFC1918
address (10.x.x.x, 192.168.x.x)
so its traffic is always forced through the NAT router. Alternatively,
you can setup some
policy routing so the Echolink traffic is always sent to the NAT
router, not routed directly.
Then you can still use AMPRnet on the same computer for other things.
The way we solved it here is by applying for BGP routing of our
subnet, so our net-44 traffic
is routed directly on internet and it is no problem to run an Echolink
repeater on it.
(the subject of this thread: will routing through UCSD cause problems
with VoIP. yes it will,
but we don't route through UCSD so we don't have that problem)
Rob
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
12:25 p.m.
New subject: AMPRNET latency in VOIP connections ?
On Tue, May 31, 2016 at 06:11:26PM +0200, 'Gustavo Ponza' wrote:
So, coming back to the original item on the subject:
if, at least,
my main server IPs 44.134.32.240 and 44.134.32.233 were
full published and routed over the internet by UCSD any problems
here should magically solved :)
They are, in fact, published and routed by UCSD, but there are two
problems with doing Echolink over that connection: one is that the
gateway is in San Diego, so packets from Italy have to travel to the
USA and back again to go a few km, and also the gateway at UCSD is not
a high bandwidth device, so there is considerable delay and jitter in
packets going through it. These delays and jitter are insignificant for
things like SMTP and other non-interactive uses, but cause disruption
on time-critical connections like VOIP.
- Brian
2:23 p.m.
New subject: AMPRNET latency in VOIP connections ?
So, coming
back to the original item on the subject: if, at least,
my main server IPs 44.134.32.240 and 44.134.32.233 were
full published and routed over the internet by UCSD any problems
here should magically solved :)
They are, in fact, published and routed by UCSD,
but there are two
problems with doing Echolink over that connection: one is that the
gateway is in San Diego, so packets from Italy have to travel to the
USA and back again to go a few km, and also the gateway at UCSD is not
a high bandwidth device, so there is considerable delay and jitter in
packets going through it. These delays and jitter are insignificant for
things like SMTP and other non-interactive uses, but cause disruption
on time-critical connections like VOIP.
- Brian
6:37 p.m.
New subject: AMPRNET latency in VOIP connections ?
On 5/31/2016 2:23 PM, 'Gustavo Ponza' wrote:
Very clear, TNX!
73, gus
two ways to solve this as well.
1. NAT the 44. address out the public internet. That is what I am doing
here.
2. have the server have two NIC cards. One with a 44 address and the
other a local non-routable which is then NATed ouot your public internet IP.
73 leon WA4ZLW
So, coming back to the original item on the subject:
if, at least,
my main server IPs 44.134.32.240 and 44.134.32.233 were
full published and routed over the internet by UCSD any problems
here should magically solved :)
They are, in fact, published and routed by UCSD,
but there are two
problems with doing Echolink over that connection: one is that the
gateway is in San Diego, so packets from Italy have to travel to the
USA and back again to go a few km, and also the gateway at UCSD is not
a high bandwidth device, so there is considerable delay and jitter in
packets going through it. These delays and jitter are insignificant for
things like SMTP and other non-interactive uses, but cause disruption
on time-critical connections like VOIP.
- Brian
1 Jun
1 Jun
4:54 a.m.
New subject: AMPRNET latency in VOIP connections ?
So, coming
back to the original item on the subject: if, at least,
my main server IPs 44.134.32.240 and 44.134.32.233 were
full published and routed over the internet by UCSD any problems
here should magically solved :)
They are, in fact, published and routed by UCSD,
but there are two
problems with doing Echolink over that connection: one is that the
gateway is in San Diego, so packets from Italy have to travel to the
USA and back again to go a few km, and also the gateway at UCSD is not
a high bandwidth device, so there is considerable delay and jitter in
packets going through it. These delays and jitter are insignificant
for
things like SMTP and other non-interactive uses, but cause disruption
on time-critical connections like VOIP.
- Brian
2907
days inactive
2908
days old
5 comments
4 participants
participants (4)
-
'Gustavo Ponza' -
Brian Kantor -
Leon Zetekoff -
Rob Janssen