[aprssig] APRS Message Callsign SPEC- Ambiguity

[Pete Loveall AE5PL Lists]

#4 is incorrect.  The transmitting callsign-SSID (your term "his TNC call") MUST be AX.25 compliant on RF and MUST match the APRS message addressee callsign-SSID that is being acked (see below).  In other words, the following will work:

AE5PL-15>APRS::WB4APR-5  :test message{01

Because the ack will be:

WB4APRS-5>APRS::AE5PL-15   :ack01

But the following will NOT work:

AE5PL-15>APRS::QIKCOMsay:test message{01

Because there is no way to transmit on AX.25:

QIKCOMsay>APRS::AE5PL-15   :ack01

Note that message numbers are not only tied to the message but also to the addressee so WB4APRS-5>APRS::AE5PL-15   :ack01 would be meaningless to AE5PL-15.  I know you believe that all message numbers are unique but they can't be for a service because of the number of messages that station might generate every day causing rollovers, etc.  Also, radios like the early Kenwoods and many software packages won't recognize a message with a duplicate message number as being new even if it has new content.  Because of these constraints, most software won't consider an ack as valid for a message sent to an addressee when that ack is from a station different from the original message addressee.

Like it or not, that is the way it works with most radios and software.

73,

Pete Loveall AE5PL
pete at ae5pl dot net


> -----Original Message-----
> From: Robert Bruninga
> Sent: Tuesday, April 26, 2016 4:47 PM
> Subject: Re: [aprssig] APRS Message Callsign SPEC- Ambiguity
> 
> Summary of APRS Messaging Constraints on the 9 byte To-ADDEE Field:
> 
> APRS Message SENT to a mixed case or non SSID 9 byte TO-ADDEE field:
> 4) RF ACKs from the 9 character ADDEE will work because the ACK is sent from
> his TNC call to the sender's TNC call