A good topic for discussion. Maybe we could designate a reflector
channel or two for testing interconnections between linking systems
(Echolink and IRLP). Much like the Western reflector (IRLP) uses 9258
for connecting to an Echolink conference bridge, we could agree that
one of the channels on a US and another on a EU reflector might be
used for this purpose. People using those channels would know that
they would not be seeing the digital information we are used to with
D-Star. It would be a decision of the reflector owners. Maybe
someone interested in this could establish a reflector dedicated to
that purpose.
The interconnections would be good for D-Star as users of the other
systems will be impressed with audio and noise-free signals and may
come on board.
Since these interconnects generally use a dongle to connect to us, I
would guess they could be kept out of other channels by restricting
dongle use but that would not be an optimal solution. It would really
depend on gentleman's agreements. I don't think we should attempt to
deny access to the busier channels as emergency situations may make
intercommunication desirable.
Ernie W6KAP
--- In dstar_digital@yahoogroups.com, John D. Hays [EMAIL PROTECTED] wrote:
I am starting this topic (and cross posting to reach as many interested
parties as possible) to open what hopefully will be a cooperative
dialog to
establish some guidelines and rules that will help foster
experimentation
and innovation on D-STAR while respecting the wishes of system
(repeaters,
gateways, and reflectors) operators. The result should be a mutally
agreeable set of terms that everyone can sign on to.
Why is this necessary?
To this point there have been a relatively few developers working on
D-STAR
projects that have any significant impact on the infrastructure. There
currently are at least two gateway replacement projects underway
(OpenDSTAR
and OpenBridge) and numerous active development projects, some open
and some
closed that can reach into the network in new ways (for example rtp_dir,
which provides an alternative to DVTOOL for accessing the network
using the
DV Dongle, but also has the capability to bridge in other networks
such as
IRLP, Allstar/Asterisk, and Echolink). The development of some of these
tools can be disruptive to systems if not properly developed and
vetted to
the community.
It is hoped that we can get a spirit of cooperation on software and
hardware
development to further D-STAR as the new Digital standard for
Amateur Radio
local and linked communications.
Here are my starting points. The guidelines should be short, to the
point,
few and clear.
Part 1 - D-STAR Reflectors
1. The owners of reflectors, repeaters, and gateways have a right to
manage
their systems in the best interests of their respective user
communities.
1.1 Use of these resources for *testing *new software and/or
hardware should
only be undertaken by the consent of the operator or their
designated agent.
1.2 *Linking* to D-STAR reflectors shall be treated equally by class of
connection. In other words if you permit software/hardware from one
developer/manufacturer, that has followed the principles of this
agreement
on your reflector, you must treat all similar technology in the class
equally. You can discriminate based on regulatory requirements of
your on
air licensing authority, illegal activity, or if the content is
generally
and consistently offensive by connection source (operator) Example
classes
include:
1.2.1 Individual operators using Internet connections by a device
like the
DV Dongle (Examples: DVTool, rtp_dir in non-bridged single operator
mode)
1.2.2 A native D-STAR gateway using G2, DPLUS, or similar linking
1.2.3 A bridged native D-STAR reflector
1.2.4 A non-native (e.g. Analog FM) repeater using a device like the DV
Dongle under automatic control.
1.2.5 A non-native reflector (IRLP or EchoLink) using a device like
the DV
Dongle under automatic control.
1.2.6 A non-native repeater or reflector with a control operator
actively
monitoring and managing the connection.
1.3 Cross linking of non-native D-STAR and D-STAR gateways,
reflectors, or
repeaters for routine networks will only be undertaken upon mutual
agreement
of the operators of the respective systems.
1.3.1 Immediate emergency communications (safety of Life or
Property) does
not require prior agreement for short linking to facilitate that
communication.
1.4 Short demonstrations by any accepted class of operation are
permitted
without prior permission if the reflector is not in active use by a
scheduled net or operating activity.
1.5 Operators of D-STAR reflectors will politely notify users, of any
connection class, if there is a problem with the use of the reflector.
1.5.1 Operators of the connecting system will comply with published
standards for a reflector..
1.5.2 If the operator of a connecting system will not comply the
