[aprssig] NOSaprs update - cross port digi with callsign substitution

[maiko at pcs.mb.ca]

Hi Bob,

> In fact I started suggesting a level 4 system
> for distributing APRS ui packets as early as 1994,
> I am thrilled to see this progress...

I'm not sure what you mean by 'progress'. From an experimental point
of view, it is not hard at all to have a user on 145.01 here in Winnipeg
do APRS with a user on 145.07 in Toronto (all without the help of the APRS
internet system). If I have an AXIP or AXUDP wormhole from my system to
the system in Toronto, it takes only one (yes, only one) DIGIPEATER call
for any of the RF users on one end to get to the RF users on the other
hand. That functionality exists in the common NOS variants out there,
and has for YEARS !

It does not even have to be a wormhole. It could be a UHF backbone with
similar aliases or digipeater calls. It's all possible, and has been for
a while.

For example, if my *gate* in winnipeg is VE4KLM, and the *gate* in toronto
is VE3MCH, I can setup a particular ALIAS (or RF DIGI CALL) on my end such
that if I heard something like the following on my end (145.01) :

    VE4IP > APRS via ONGATE
    :VE3TOK   :Hi Bob, how's the weather in Toronto ?

My system will see the ONGATE, pass this packet to VE3MCH, which in turn
would automatically put it out on 145.07 in Toronto. It would come out :

    VE4IP > APRS via VE3MCH-3
    :VE3TOK   :Hi Bob, how's the weather in Toronto ?

and be heard by ANYONE on that frequency. A similar gate could be built
on the Toronto side to do the same back to Winnipeg. So if Bob wanted to
send something back to me, he could have an MBGATE alias or whatever.

This IS very possible today, and has been possible for years ! It simply
requires that people know in advance what their digicalls need to be to
get to a particular location.

> But I was just pointing out the pitfalls ...

No problem. This is education for me. I am falling behind. I just took
a quick look at your 'Fixing the 144.39 APRS Network' page, The New n-N
Paradigm at 'http://web.usna.navy.mil/~bruninga/aprs/fix14439.html'.

It probably would not hurt for me to brush up on things, and update.

Here's a novel concept (perhaps not) ...

Did it occur to anyone that perhaps a key issue is that the
APRS sender (user) has too much control over their routing ?
The system should do the routing, the sender should only
need to provide the APRS packet. The system could manage
traceability via user interfaces or utilities.

If I'm sitting at my desk, all my ip packets go through
a default router in our department and out to the rest of
the world. I certainly don't need to add the equivalent
of a WIDE2-2 or ECHO or whatever. I let the system do
that for me.

If a local user did not want the system to digi it out
any further, they could OPT OUT (there's a concept) by
perhaps doing a VE4KLM > APRS via NODIGI or something.

I personally can't see any reason for me to decide that
I only want my packets to go a specific distance. It's of
no concern to me. I just want to be able to talk to the
person that I'm looking for. Let the system do it, and
then there is no chance of me overwhelming the network
because I was ignorant enough to use a WIDE7-7, etc.

Just a thought ...

> NOTE: I am not arguing against path modification in any way,
> its  only that the only paths that should be modified are paths
> that the sender KNOWS before hand *are potential for
> modification*

Then take those paths away from the sender, and let the system
do it. Then make sure that your users know that the system will
append CERTAIN digicalls to the path.

> No, its like you calling CQ on 3650 and having
> someone in  California, Colorado and Alabama
> patching it over to their local VHF repeater.
> Your name and call would be mud.

That's not a realistic example :-)

> Again, I am not at all discouting your objectives,
> only pointing out that the existing generic APRS
> paths of WIDE, RELAY, and WIDEn-N should not
> be mnodified along the way beyond their published
> expectations or the integrity of the system is being
> compormised.

Understood.

> So again, not at all picking at your objectives and
> intents.  Just wanted to clarify the paticular
> pitfalls of your specific example.

No problem.

Maiko