[aprssig] Msg reply path (for SSn-N)

[Robert Bruninga]

>  What about the acks?  I get a message... [from] five hops away
> on a SS5-5 path and my acks only go out WIDE2-2.

Now that might be a good idea.  I agree with Lynn that there are so
many marginal, misconfigured, and obsolete digis out there that
revers-pathing will only create as many problems as it solves.

BUT, in this specific case, of an SSn-N packet, maybe it is a good
idea to change the ACK from the standard (usually WIDEn-N) to a
returning SSn-N.  Reason being, it is the ONLY way the ack could get
back and if it was received, then apparently surrounding digis support
SSn-N.

I'd suggest that client softwware have a setting for MYSSn-N's so that
the operator can indicate the SSn-Ns in his area.  There are so many
and they can be locally strange that the client should not have to
figure out what is an SSn-N call but can use from its configured set.
In that case, I'd suggest a list of 4.  That way someone lliving in he
corner of a state but that has interest in surrounding states can
participate.

Maybe the list is not needed, and the client can just recognize
anything  of the form XX..# - # that is not WIDE or TEMP or TRACE?

Bob, Wb4APR


On Fri, Oct 4, 2013 at 6:10 PM, Tony VE6MVP <tony at ve6mvp.com> wrote:
> At 04:23 AM 2013-10-04, Lynn W. Deffenbaugh (Mr) wrote:
>
> <snip>
>
> So, until all of the above are completely gone from the network and the
> entire planet is fully WIDEn-N compliant (which means replacing a bunch of
> obsolete hardware that cannot be made fully compliant), I for one am not
> going to release software whose default settings don't work in some areas.
> The support aspects are overwhelming.
>
>
> Fair enough.   I keep forgetting about those because I don't see any in my
> usual area of travel in western Canada.    Leave the settings to default as
> is then but give the rest of the amateur population the abiltity to enable
> the proper tools to use the APRS system in the proper fashion.
>
> Besides, just because you received a message that says AB7-3 doesn't mean
> you need to transmit an entire AB7-7 path.  In actual fact an AB7-4 or AB7-5
> might be sufficient.  Only a human can know for sure (or at least make a
> better guess).
>
>
> Sure but so what.    xx7-7 is only going to be used for occasional testing
> and disasters.  Normally from my location I'd use AB7-3 to get into the big
> city.
>
> And the logical extension to this is to simply reverse the used portion of
> the path asking the response message to go back out through the digipeaters
> that delivered it.  That also doesn't work because it's not necessarily true
> that if A can hear B on the way here then B can hear A on the way back.
> Reversing used digipeaters explicitly is, IMHO, less likely to succeed than
> using a beefed-up alias.
>
>
> I do completely agree with your reasoning there.   One of the very nice
> features of the APRS system is the redundant nature of the network of digi's
> and the dupe suppression of the digi's.
>
> Now, if you were to ask software authors to make the received path of
> message packets visible to the user and provide a QSO-specific
> manually-entered outbound message path override (which of course, defaults
> to the station's normal beacon path), that might be a step in the right
> direction.
>
>
> That's be a step but in my opinion only a partial one.  What about the acks?
> I get a message from James VE6SRV who is five hops away on an AB path and my
> acks only go out WIDE2-2.   So now my system sends out a number of acks that
> will never, ever make it to him.
>
> Tony
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>