I have been doing a lot of thinking about a new D-STAR Architecture
(and hope to provide some more concrete material at some point), but
this discussion brings up some basic ideas that have been percolating
in my ruminations.
Icom started from a different model than community usage patterns
suggest is the proper way to do things.
Here are some of the design principles that I think are important:
1 - Internet connected devices need an easy mechanism for discovery -
use Secured Dynamic DNS. (Set TTLs based on likelihood of IP Address
changes (static IPs have very long TTLs, dynamic TTLs very short)
2 - Have a low latency, redundant and reliable service to map radio/
repeater/simplex node/gateway/service Callsign Addresses to DNS
names. Maybe something like a Cassandra (Apache) cluster. (Use caches
on local boxes for the "working set of callsigns" that a local system
needs, don't copy full databases around.)
3 - User authentication - completely eliminate registration for RF
devices that use Callsigns, since Callsign Addresses are sent "in the
clear" anyone can forge them (pirate the callsign) and pretend that it
is a control mechanism is ludicrous. Use of false / pirated callsigns
is illegal in most, if not all, countries. Legal prosecution for
false callsigns is probably a better deterrent than a silly
"registration" system. A fairly simple regular expression could
filter "MY" callsigns to make sure they at least look like a
legitimate callsign, here is a Java Example/Test code for callsign
checking, including a mark for VK foundation licenses (who are not
permitted to use D-STAR):
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
public class DstarCallsignCheck {
public static void main(String[] args) {
BufferedReader stdin = new BufferedReader(new
InputStreamReader(
System.in));
String foundation = "^VK[0-9]F[A-Z]{3}.*$"; //
Australian Foundation Class
String DstarCallsign8c = "[A-Z0-9]{1}[A-Z0-9]{0,1}
[0-9]{1}[A-Z ]{4,8}
[A-Z 0-9]{0,1}|CQCQCQ |REF[0-9]{3}[0-9 ]{1}[A-Z 0-9]$";
while (true) {
try {
System.out.print("Callsign: ");
String call =
stdin.readLine().toUpperCase();
while (call.length() < 8) call += "
"; // Space end padding.
System.out.println("[" + call + "] "
+ call.length());
if (call.length() != 8)
System.err.println("Call must
be exactly 8 characters");
// too long of callsign
else {
System.out.println("D-STAR
Call "
+
(call.matches(DstarCallsign8c) && ! call.substring
(0,2).matches("\\d{2}")));
System.out.println("VK
Foundation Class Call "
+
call.matches(foundation));
}
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
}
4. Authorization - some system operators will want to control access
to their radio receiver and transmitter based on user callsigns,
provide filters in the "gateway" to enable them to have access and
deny lists. These lists could include, by reference, databases such
as are found in the G2 "terminal registration", national callsign
databases, regional databases, and local databases/hashtables for
local control. (Those of you who believe in "registration" could
filter out anyone who was not in one of these databases.)
5. Callsign routing. It is basic to the protocol and should always be
permitted. (It may be necessary to "barge in" on a linked repeater
for emergency or other timely traffic) A gateway/repeater could be
designed to relay (with buffering) the incoming callsign routed
transmission and send an automatic reply to the sender informing them
of the "linked" or other service running that they might be disrupting.
6. Linking. All linking should be through a robust and dynamic
"reflector" system. Even two repeaters should use a reflector to
allow a third repeater to join the conversation.
7. Regional linked systems should be treated as a single gateway by
the rest of the network, sort of like a super repeater.
8. Pure Internet/Non-RF devices (like the DV-Dongle) should have a
strong authentication/authorization service, but then be treated like
peers on the network. (Some sort of list of callsigns could be
provided by the service and used in #4 above to allow or deny them
access to a given gateway/repeater.)
I have a lot more implementation ideas, and other enhancements, but
these are the fundamentals. Well known interfaces would permit
different authors to write the various components.
John D. Hays
Amateur Radio Station K7VE
PO Box 1223
Edmonds, WA 98020-1223 VOIP/SIP: [email protected]
Email: [email protected]
