My previous post on D-STAR <--> legacy interoperability focused on the voice side of things. However, D-STAR is more than just voice. There is also a data channel to consider, which could be useful. Now, what could we do with the data channel to interact with other systems?
1. Link the data channel to an EchoLink conference. If software such as D-RATS is mediating the link, text messages could be filtered out from other data such as file transfers and GPS co-ordinates and then passed onto the EchoLink side. And EchoLink messages could be converted to D-RATS text messages and sent to the D-STAR radio. Other options for bridging D-RATS messaging include Internet based services, such as a private Jabber server, open only to hams, APRS messages or packet radio converse bridges.
2. DPRS GPS data is already being gated to the APRS network, so there is already some interoperability with the data channel today.
3. File transfers and other non text data require a bit more thought. Some of this could be passed to a Jabber based system (since Jabber supports file transfers).
In any case, this integration of D-STAR and non D-STAR messaging and data transfer will require similar policies and access controls to that discussed for voice bridges.
Tuesday, November 25, 2008
D-STAR <--> IRLP/Echolink Interoperability
Recently, there has been a lot of talk about the place (if any) analogue and legacy linking systems such as IRLP and EchoLink have in the D-STAR world. This was precipitated by some unauthorised testing conducted on D-STAR reflectors and gateways by the author of one of the EchoLink compatible packages. As one would expect, the D-STAR administrators who were affected were very upset at this development, and there is now a lot of tension surrounding this issue. Some D-STAR people want nothing to do with analogue, and make various arguments, from the annoyance of improperly configured repeater links, to incompatibilities with the way D-STAR works. For the most part, these arguments have a lot of merit.
However, I believe that keeping both systems totally separate is short sighted, but on the other hand, uncontrolled cross-system linking is just going to annoy a lot of people and render D-STAR, and possible the legacy systems unusable. However, in the middle ground, there is room for some limited and controlled interconnection between EchoLink/IRLP and D-STAR, as well as standalone FM systems. For me, this is not a new issue. Many in the IRLP and EchoLink worls will remember that I was one of the primary developers of EchoIRLP, and I am also responsible for the integrated IRLP/EchoLink conferences, such as IRLP reflector 9219/*WX_TALK*, which is depended upon during the US hurricane season. Like now, initially, there was a lot of hostility towards linking IRLP to EchoLink, but these issues were resolved, by adopting a set of guidelines that respected the rights of system owners to control what traffic they see, and allow flexibility for interconnection. The original discussion and guidelines from 2002 are still on the web at http://vkradio.com/irlp-echolink.html .
In the same spirit, I would like to offer a similar set of guidelines that those interested in integrating D-STAR with other networks can follow. While D-STAR is quite different, and the feature set has less overlap with IRLP, EchoLink or standalone FM systems, I believe there is still some room to interconnect the different systems under specific circumstances. Again, the emphasis will be on giving the respective admins crontrol over their systems, while offering the users some options.
To save double handling, I will now post the guidelines, which I've copied and pasted from an email I sent to the dstarsoftware Yahoo group on November 19, 2008.
After an email discussion with a German amateur friend from IRLP, I managed to collect a few thoughts on the whole D-STAR - IRLP/Echolink issue. By borrowing a few ideas from EchoIRLP and the whole IRLP/Echolink interoperability issue, I have formulated a similar set of proposals for D-STAR. I would like to throw the ideas here for consideration:
First, the proposal attempts to meet the following guidelines:
1. No non-D-STAR system can connect to a D-STAR reflector or gateway without the owner's approval. The owners must be the ultimate authority of what connects to their systems.
2. There are two levels of interoperability - one requires gateway modification, but offers more flexibility. The other involves no gateway modifications, but is limited to designated places where the different systems can "mingle".
3. No accidental crosslinks are possible. For example, I don't want it to be possible to connect via Echolink to my local D-STAR gateway and then be broadcast on the national D-STAR reflector. Lockouts would need to be built in to prevent this. Similarly, no deliberate crosslinks should be possible, especially ones where the remote gateway could be commanded to make a bridge. While bridging is sometimes desirable for unusual circumstances, this should always be a manual operation directly controlled by the gateway or reflector owner.
For a more thorough explanation of these rules (until I get around to throwing up a blog with updated information), the following page should give an idea of where I'm coming from. (Note added Nov 25 - this is that page :D ).
http://vkradio.com/irlp-echolink.html
While this was written 6 years ago in the context of IRLP and Echolink, I believe the underlying principles are still valid here.
Anyway, here goes, first with a recap on what happened between IRLP and Echolink.
There ended up being 3 scenarios for IRLP <--> Echolink interoperability.
1. EchoIRLP - allows individual IRLP nodes to also become native Echolink nodes.
2. Linked conferences - IRLP reflector channels linked to Echolink conferences. One of the best known examples of this configuration is the VK National Network. The Western Reflector (925x) also has a few linked channels.
3. Integrated/shared conferences - These allow both IRLP and Echolink stations to connect directly to the same physical server. This gives more transparency and control over operations. Example IRLP 9219/*WX_TALK*, which is used for US hurricane nets.
Admins should have the right to decide what passes through their system. That was one of the cornerstones of EchoIRLP and the whole IRLP-Echolink interoperability ideals.
The issues back then were posted at http://vkradio.com/irlp-echolink.html , which helped put a lot of node owners' minds at ease. Once people realised what EchoIRLP was trying to do, opinion rapidly changed from hostile to "this is a great idea". Not sure how many EchoIRLP nodes there are today, but seems to be a lot around. Scott's work has added to that count also, as a number of EchoIRLP like nodes now use rtpDir. :) There are 999 subscribers to the EchoIRLP Yahoo group as of November 2008.
Anyway, at this stage, we can say there are two workable (possibly more will be discovered) interoperability scenarios for D-STAR and IRLP/Echolink.
1. Linked reflectors/conferences. Setup a dedicated reflector or two on the D-STAR side, and also on the IRLP/Echolink side and link them together using rtpDir (or other suitable software). I'm more than happy to provide resources and run a D-STAR reflector. I could possibly add a new Echolink conference as well for the project. My transcoding hardware and software would be available for formal trials (I don't want to leave the big system on 24x7, and also want to leave my resources free for emergency operations). With some co-operation from Robin AA4RC to install and configure the new reflector, this scenario is feasible today.
As no such reflector exists on the D-STAR side, I would like to offer my services to host a reflector dedicated to cross system linking on a high bandwidth site. I plan on using the 3 channels as follows:
A - EMCOMM and formal exercises only - cross links would be ones I setup or permit.
B - General ragchew. A single crosslink between this channel and an appropriate Echolink conference. Other than providing resources, I don't anticipate having much input into the workings here.
C - Open testing. This channel would have no limits on who can setup links. The idea being to have a place to test setups. Normal amateur courtesy would apply.
2. Multi system node. This would require rtpDir (or alternative), a DV Dongle and possibly a new Gateway addon (similar to dplus) to be installed at the gateway. The addon would manage the interaction between dplus and rtpDir to prevent accidental cross links to the general dplus network (similar to how the EchoIRLP control scripts work). The Dongle is required, because the gateways have no audio processing hardware on board, and we need raw (PCM) audio to be able to transcode to the formats used by IRLP and Echolink. rtpDir, of course, would manage the connections to Echolink and IRLP (hmm, running IRLP on a gateway, that would be an interesting technical project).
Challenges:
1. Echolink callsigns are often invalid in the D-STAR world. Might have to use node numbers instead. For example, to link to *VKEMCOMM*, you might need to have users setup their radios like:
MY VK3JED
UR 270177 L
R1 VK3RWN B
R2 VK3RWN G
which translates to
"Connect to Echolink node number 270177".
For an IRLP connection, you would have something like the above, but with
UR STN6390L
to connect to my IRLP node, or
UR REF9508L
Or alternatively, to avoid clashes with the existing dplus codes, an IRLP connection could be specified like:
UR 9508 I
or
UR REF9508I
where I stands for "connect to IRLP", and a similar suffix could be used for Echolink to avoid clashing with dplus.
UR 270177 K (for echolinK, don't want to use E, since that already has special meaning in dplus).
to connect to IRLP reflector 9508.
Not sure if the dplus ^^^^^^UL command would be appropriate to drop the connection or if there would be conflicts. Robin would be the person to consult there.
2. Getting IRLP and the gateway software to play nicely on the same box for IRLP connections. Parts of IRLP are needed to be able to connect to the IRLP network.
Anyway, just throwing a few thoughts into the ring. I'd like to see this issue resolved for the benefit of all. For Gateway operators like Mike who doesn't want any analogue traffic passing through their systems, by not installing the add ons and locking out the interconnected reflector(s), you can keep analogue traffic off your systems. Other operators can decide how much they want to participate.
However, I believe that keeping both systems totally separate is short sighted, but on the other hand, uncontrolled cross-system linking is just going to annoy a lot of people and render D-STAR, and possible the legacy systems unusable. However, in the middle ground, there is room for some limited and controlled interconnection between EchoLink/IRLP and D-STAR, as well as standalone FM systems. For me, this is not a new issue. Many in the IRLP and EchoLink worls will remember that I was one of the primary developers of EchoIRLP, and I am also responsible for the integrated IRLP/EchoLink conferences, such as IRLP reflector 9219/*WX_TALK*, which is depended upon during the US hurricane season. Like now, initially, there was a lot of hostility towards linking IRLP to EchoLink, but these issues were resolved, by adopting a set of guidelines that respected the rights of system owners to control what traffic they see, and allow flexibility for interconnection. The original discussion and guidelines from 2002 are still on the web at http://vkradio.com/irlp-echolink.html .
In the same spirit, I would like to offer a similar set of guidelines that those interested in integrating D-STAR with other networks can follow. While D-STAR is quite different, and the feature set has less overlap with IRLP, EchoLink or standalone FM systems, I believe there is still some room to interconnect the different systems under specific circumstances. Again, the emphasis will be on giving the respective admins crontrol over their systems, while offering the users some options.
To save double handling, I will now post the guidelines, which I've copied and pasted from an email I sent to the dstarsoftware Yahoo group on November 19, 2008.
After an email discussion with a German amateur friend from IRLP, I managed to collect a few thoughts on the whole D-STAR - IRLP/Echolink issue. By borrowing a few ideas from EchoIRLP and the whole IRLP/Echolink interoperability issue, I have formulated a similar set of proposals for D-STAR. I would like to throw the ideas here for consideration:
First, the proposal attempts to meet the following guidelines:
1. No non-D-STAR system can connect to a D-STAR reflector or gateway without the owner's approval. The owners must be the ultimate authority of what connects to their systems.
2. There are two levels of interoperability - one requires gateway modification, but offers more flexibility. The other involves no gateway modifications, but is limited to designated places where the different systems can "mingle".
3. No accidental crosslinks are possible. For example, I don't want it to be possible to connect via Echolink to my local D-STAR gateway and then be broadcast on the national D-STAR reflector. Lockouts would need to be built in to prevent this. Similarly, no deliberate crosslinks should be possible, especially ones where the remote gateway could be commanded to make a bridge. While bridging is sometimes desirable for unusual circumstances, this should always be a manual operation directly controlled by the gateway or reflector owner.
For a more thorough explanation of these rules (until I get around to throwing up a blog with updated information), the following page should give an idea of where I'm coming from. (Note added Nov 25 - this is that page :D ).
http://vkradio.com/irlp-
While this was written 6 years ago in the context of IRLP and Echolink, I believe the underlying principles are still valid here.
Anyway, here goes, first with a recap on what happened between IRLP and Echolink.
There ended up being 3 scenarios for IRLP <--> Echolink interoperability.
1. EchoIRLP - allows individual IRLP nodes to also become native Echolink nodes.
2. Linked conferences - IRLP reflector channels linked to Echolink conferences. One of the best known examples of this configuration is the VK National Network. The Western Reflector (925x) also has a few linked channels.
3. Integrated/shared conferences - These allow both IRLP and Echolink stations to connect directly to the same physical server. This gives more transparency and control over operations. Example IRLP 9219/*WX_TALK*, which is used for US hurricane nets.
Admins should have the right to decide what passes through their system. That was one of the cornerstones of EchoIRLP and the whole IRLP-Echolink interoperability ideals.
The issues back then were posted at http://vkradio.com/irlp-
Anyway, at this stage, we can say there are two workable (possibly more will be discovered) interoperability scenarios for D-STAR and IRLP/Echolink.
1. Linked reflectors/conferences. Setup a dedicated reflector or two on the D-STAR side, and also on the IRLP/Echolink side and link them together using rtpDir (or other suitable software). I'm more than happy to provide resources and run a D-STAR reflector. I could possibly add a new Echolink conference as well for the project. My transcoding hardware and software would be available for formal trials (I don't want to leave the big system on 24x7, and also want to leave my resources free for emergency operations). With some co-operation from Robin AA4RC to install and configure the new reflector, this scenario is feasible today.
As no such reflector exists on the D-STAR side, I would like to offer my services to host a reflector dedicated to cross system linking on a high bandwidth site. I plan on using the 3 channels as follows:
A - EMCOMM and formal exercises only - cross links would be ones I setup or permit.
B - General ragchew. A single crosslink between this channel and an appropriate Echolink conference. Other than providing resources, I don't anticipate having much input into the workings here.
C - Open testing. This channel would have no limits on who can setup links. The idea being to have a place to test setups. Normal amateur courtesy would apply.
2. Multi system node. This would require rtpDir (or alternative), a DV Dongle and possibly a new Gateway addon (similar to dplus) to be installed at the gateway. The addon would manage the interaction between dplus and rtpDir to prevent accidental cross links to the general dplus network (similar to how the EchoIRLP control scripts work). The Dongle is required, because the gateways have no audio processing hardware on board, and we need raw (PCM) audio to be able to transcode to the formats used by IRLP and Echolink. rtpDir, of course, would manage the connections to Echolink and IRLP (hmm, running IRLP on a gateway, that would be an interesting technical project).
Challenges:
1. Echolink callsigns are often invalid in the D-STAR world. Might have to use node numbers instead. For example, to link to *VKEMCOMM*, you might need to have users setup their radios like:
MY VK3JED
UR 270177 L
R1 VK3RWN B
R2 VK3RWN G
which translates to
"Connect to Echolink node number 270177".
For an IRLP connection, you would have something like the above, but with
UR STN6390L
to connect to my IRLP node, or
UR REF9508L
Or alternatively, to avoid clashes with the existing dplus codes, an IRLP connection could be specified like:
UR 9508 I
or
UR REF9508I
where I stands for "connect to IRLP", and a similar suffix could be used for Echolink to avoid clashing with dplus.
UR 270177 K (for echolinK, don't want to use E, since that already has special meaning in dplus).
to connect to IRLP reflector 9508.
Not sure if the dplus ^^^^^^UL command would be appropriate to drop the connection or if there would be conflicts. Robin would be the person to consult there.
2. Getting IRLP and the gateway software to play nicely on the same box for IRLP connections. Parts of IRLP are needed to be able to connect to the IRLP network.
Anyway, just throwing a few thoughts into the ring. I'd like to see this issue resolved for the benefit of all. For Gateway operators like Mike who doesn't want any analogue traffic passing through their systems, by not installing the add ons and locking out the interconnected reflector(s), you can keep analogue traffic off your systems. Other operators can decide how much they want to participate.
Subscribe to:
Posts (Atom)