Connecting 2 reflectors with each other


Ken Arck
 

Is is possible?

------------------------------------------------------------------------------
President and CTO - Arcom Controllers
Makers of repeater controllers and accessories
Phone: (503) 678 6182
https://www.arcomcontrollers.com/
Authorized Dealers for Kenwood and Telewave.
We offer complete turn-key repeater packages!
AH6LE/R - IRLP Node 3000
http://www.irlp.net
"We don't just make 'em. We use 'em!"
[]


Dave K9DC
 

Is this a technical question, or a policy question?
-k9dc

On Jul 9, 2021, at 21:08, Ken Arck <ken@arcomcontrollers.com> wrote:

Is is possible?


Ken Arck
 

Both I suppose <g>


At 06:08 PM 7/9/2021, you wrote:
Is is possible?

------------------------------------------------------------------------------
President and CTO - Arcom Controllers
Makers of repeater controllers and accessories
Phone: (503) 678 6182
https://www.arcomcontrollers.com/
Authorized Dealers for Kenwood and Telewave.
We offer complete turn-key repeater packages!
AH6LE/R - IRLP Node 3000
http://www.irlp.net
"We don't just make 'em. We use 'em!"
[]





------------------------------------------------------------------------------
President and CTO - Arcom Controllers
Makers of repeater controllers and accessories
Phone: (503) 678 6182
https://www.arcomcontrollers.com/
Authorized Dealers for Kenwood and Telewave.
We offer complete turn-key repeater packages!
AH6LE/R - IRLP Node 3000
http://www.irlp.net
"We don't just make 'em. We use 'em!"
[]


Bill Hudson
 

Ken

Simple - back to back nodes, cross the COR to PTT from each node (both
ways), and cross the send and receive audios and you have it done. The
tough part is controlling nodes with either an SSH session or a vCon
session.

If you're good with coding, you can write a script with a prefix and then
DTMF Generate from one node to the other to control it. That level of
detail takes more space on the page...:-)

Bill

-----Original Message-----
From: IRLP@irlp.groups.io [mailto:IRLP@irlp.groups.io] On Behalf Of Ken Arck
Sent: Friday, July 9, 2021 6:42 PM
To: IRLP@irlp.groups.io
Subject: Re: [IRLP] Connecting 2 reflectors with each other

Both I suppose <g>


At 06:08 PM 7/9/2021, you wrote:
Is is possible?

---------------------------------------------------------------------------
---
President and CTO - Arcom Controllers
Makers of repeater controllers and accessories
Phone: (503) 678 6182
https://www.arcomcontrollers.com/
Authorized Dealers for Kenwood and Telewave.
We offer complete turn-key repeater packages!
AH6LE/R - IRLP Node 3000
http://www.irlp.net
"We don't just make 'em. We use 'em!"
[]





----------------------------------------------------------------------------
--
President and CTO - Arcom Controllers
Makers of repeater controllers and accessories
Phone: (503) 678 6182
https://www.arcomcontrollers.com/
Authorized Dealers for Kenwood and Telewave.
We offer complete turn-key repeater packages!
AH6LE/R - IRLP Node 3000
http://www.irlp.net
"We don't just make 'em. We use 'em!"
[]








--
This email has been checked for viruses by AVG.
https://www.avg.com


Nosey Nick VA3NNW
 

Bill Hudson wrote:
Simple - back to back nodes, cross the COR to PTT from each node
Great! ... for 2 nodes.

What about 2 reflectors, like the subject line says?

I'm pretty sure the answer is YES, I've seen diagrams of reasonably complicated reflector networks, but I'm curious about the details of how.

Nick VA3NNW

--
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209, IRLP #2410
use Std::Disclaimer; sig@noseynick.net
What happened to the first 6 "ups"?


Dave K9DC
 

From a technical perspective it is possible. In fact it is sort of done with the creation of Listen Only channels of weather or other emergency nets.

From a policy standpoint it doesn’t make much sense. Reflectors generally are located in data centers with plenty of available bandwidth. Reflectors cannot make outbound calls, therefore setups have to be made manually in advance. But it is difficult to manage connected reflectors, plus it would add additional latency. Bottom line, it usually doesn’t make sense and there is little need.

Do you have a specific application in mind where you think it would be useful?

-k9dc

On Jul 9, 2021, at 21:42, Ken Arck <ken@arcomcontrollers.com> wrote:

Both I suppose <g>


 

On 10/7/21 11:08 am, Ken Arck wrote:
Is is possible?
Short version:  Yes, under certain conditions, from a technical standpoint.

Longer version is that a few conditions need to be met, for technical
reasons.  I will say I have done this.  9550 used to be linked to 9500,
and was known as the "Virtual Pub Back Bar".  This was done partly as an
experiment, partly for redundancy.  This link is no longer the case,
because 9500 is now run by a different party, and 9550 has been repurposed.

There's a few possible scenarios.

1.  Listen only - this can (I think) be done with the standard sfreflect
software on both ends.  sfreflect does, or at least did have a feature,
where it could send a stream to another IP address in one direction. 
Ideally, both reflectors should be configured to run the same codec
(though IRLP nodes tend to adjust for different codec styles.  Suitable
permissions can be configured on the destination reflector.

2.  Full transceive - easy (and known working) case.  This is how I did
it for the 9550 - 9500 link.  A few conditions needs to be met:

a). Both reflectors need to use the same channel ( 0 - 0, 1 - 1, 2 - 2,
etc).

b).  Both of the reflectors need to be using the same codec on the
shared channel (it may be possible to have tlb transcode, but I haven't
tested this for side effects).

c).  One of the reflectors needs to be running tbd or tlb.  This is
because only tbd or tlb can initiate a full connection to a target IP. 
tbd/tlb needs to be configured as a conference for the desired codec. 
The target reflector can run sfreflect (it did in my case), or tlb/tbd.

d).  Of course, the reflector making the connection needs to be given
permission to connect by the destination reflector, using the inbuilt
access control mechanisms.


3.  The more complex case - link arbitrary channels, transcode, etc. 
This requires _two_ copies of tlb or tbd (only tlb if transcoding) and
an additional IP address, and careful configuration to avoid port
conflicts.  I haven't tried this setup, so it's purely theoretical from
my viewpoint.  The reason for the complexity is when you initiate a
Speak Freely (IRLP audio) connection to another host on a port other
than the configured default, tlb/tbd opens up the same ports for
incoming traffic.  This is because the Speak Freely protocol expects
traffic between the same ports on both end (except in special
configurations).  And on an IRLP reflector, this behaviour interferes
with other channels on the same reflector.  Hence the need to use a
separate IP and careful use of SF_Bind2IP.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


 

On 10/7/21 12:05 pm, Bill Hudson wrote:
Ken

Simple - back to back nodes, cross the COR to PTT from each node (both
ways), and cross the send and receive audios and you have it done. The
tough part is controlling nodes with either an SSH session or a vCon
session.
Possible, yes, but in practice, and ugly method, that can result in
audio degradation and increased latency.  This used to be done for
transcoding between IRLP and Echolink (*WX-TALK* and REF9210), in the
early days of the VoIP WX Net (2004), and was the incentive to develop a
software based method to link IRLP and Echolink.  By 2005, the first
generation of integrated conference replaced this setup, with the IRLP
side being moved to 9219, where it is today, and *WX-TALK* being moved
to run Echolink/IRLP from the one tbd binary.

I gave a presentation on this technology at the 2005 IRLP conference in
Las Vegas, as well as EchoIRLP.

in 2009, the integrated conference was redesigned to work with the new
security model of the reflectors, and several new features were added. 
I again gave a presentation at the conference in Vegas in 2010, except
this time, I did it from home over Skype.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


David Cameron - IRLP
 

There is an issue with pointing the "monitor" stream from one sfreflect instance to another. It can get caught in a loop because of the way the reflector handles control packets.

I have been using a program called samplicator to get around that. It listens on a UDP port/IP (localhost is fine) and retransmits the packets to other IPs. You can send only the data packets this way, and block the control packets which can cause issues.

I suspect that someone is trying to do something similar on 9050, as it can get into a tizzy and send lots of unwanted control packets.

Dave Cameron

On 2021-07-09 8:48 p.m., Dave K9DC via groups.io wrote:
From a technical perspective it is possible. In fact it is sort of done with the creation of Listen Only channels of weather or other emergency nets.
From a policy standpoint it doesn’t make much sense. Reflectors generally are located in data centers with plenty of available bandwidth. Reflectors cannot make outbound calls, therefore setups have to be made manually in advance. But it is difficult to manage connected reflectors, plus it would add additional latency. Bottom line, it usually doesn’t make sense and there is little need.
Do you have a specific application in mind where you think it would be useful?
-k9dc

On Jul 9, 2021, at 21:42, Ken Arck <ken@arcomcontrollers.com> wrote:

Both I suppose <g>


 

Good to know Dave.  I haven't used the monitor stream myself, only tlb
or tbd, which initiates a full connection without issues (provided you
only use the same channel number on each end).

On 11/7/21 3:30 am, David Cameron - IRLP wrote:
There is an issue with pointing the "monitor" stream from one
sfreflect instance to another. It can get caught in a loop because of
the way the reflector handles control packets.

I have been using a program called samplicator to get around that. It
listens on a UDP port/IP (localhost is fine) and retransmits the
packets to other IPs. You can send only the data packets this way, and
block the control packets which can cause issues.

I suspect that someone is trying to do something similar on 9050, as
it can get into a tizzy and send lots of unwanted control packets.

Dave Cameron





On 2021-07-09 8:48 p.m., Dave K9DC via groups.io wrote:
From a technical perspective it is possible.  In fact it is sort of
done with the creation of Listen Only channels of weather or other
emergency nets.
From a policy standpoint it doesn’t make much sense. Reflectors
generally are located in data centers with plenty of available
bandwidth. Reflectors cannot make outbound calls, therefore setups
have to be made manually in advance. But it is difficult to manage
connected reflectors, plus it would add additional latency. Bottom
line, it usually doesn’t make sense and there is little need.
Do you have a specific application in mind where you think it would
be useful?

-k9dc


On Jul 9, 2021, at 21:42, Ken Arck <ken@arcomcontrollers.com> wrote:

Both I suppose <g>








--
73 de Tony VK3JED/VK3IRL
http://vkradio.com