Callsign Length Greater Than 6 characters

[johnhays]

One issue found with the D-STAR protocol is that sometimes countries issue callsigns that are greater than 6 characters (Australia foundation class for example and special event callsigns in various jurisdictions)

Also for proper identification there may be a prefix or suffix, e.g. (W7/G3XXX or NN1XXX/P)

The base40 encoding allows additional characters, but in general I would advocate at least the callsign be plain text to meet identification requirements.

Also, there should be flexibility for new 'destination' and 'source' nodes that do not fit into current conventions (e.g. the patterns for reflectors, talk groups, etc.)

Perhaps an addition packet type for 'regulatory identification' should be added.

[kc1awv]

Hi John,

The current spec calls for 9 characters, using up 6 bytes. Appendix A. https://m17-protocol-specification.readthedocs.io/en/latest/address_encoding.html

Is there a need for more than 9 characters?

Let me just clarify, any 9 characters can be encoded into something that M17 can use. We have a tool for this, as well: https://m17project.org/calculator/

I'm not 100% sold on needing more than this. Reflectors are M17-XXX[space][A-Z] and AU callsigns for foundation licenses are 7 characters, allowing for two more characters, like /P or -M.

I understand special event calls, like the callsigns used by countries that were promoting self isolation during pandemic times, but these topics seem to have faded away.

[johnhays]

Examples ZL/VK3BFHK (10) VE/VK3BFHK/M (12) NH6QRZ/WA2ABC/AE/P (20) see https://www.law.cornell.edu/cfr/text/47/97.119 (particularly paras e and f) And the spec achieves 9 characters via Base 40 encoding. I would think some regulators would want plain text for ID hence a DMR ID not being a legal station ID, even though a DMR radio might have a database to look up the associated callsign. One of the issues with protocols that don't look ahead is that they become problematic as technology moves forward (AX.25 address + SSID, D-STAR, DMR, ...) other than the callsign, which I believe should be plain text, the use of the full 8 bits of an octet can be encoded, e.g. 256 ssids in an octet or use 2 octets and have 65k ssids. Also such things as overloading commands on to callsign fields should be discouraged as they create ambiguity. Commands like link and unlink should have their own field or even packet type. A lot of the earlier designs did not envision high compute and memory components in nodes which meant squeezing every functionality out of a bit. (When I was on the ANSI/X9 banking committee, twenty years ago, we were severely limited by 80 character data representations due to hollerith cards being the early standard in data processing, and we spent days debating reallocating a single character -- they now have JSON versions).

…

On Fri, Apr 16, 2021 at 2:29 PM Steve Miller ***@***.***> wrote: Hi John, The current spec calls for 9 characters, using up 6 bytes. Appendix A. https://m17-protocol-specification.readthedocs.io/en/latest/address_encoding.html Is there a need for more than 9 characters? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#50 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABR7I6W77NHWQ5MHF2F7TK3TJCTZZANCNFSM43CHS4XQ> .

-- John D. Hays Kingston, WA K7VE / WRJT-215

[kc1awv]

Personally, I think the examples given are a bit extreme for a VHF and up mode. But that's my opinion.

Some things to consider:

• on air time for the LSF
• Regulatory requirements outside of the US
• Unicode? (Basic Latin, let's not go crazy)
• Actual reasonable length for source / destination

If you have any comments for this, please let us know! I'll have to set up a lab to test the efficacy of random lengths for the LSF.

[mobilinkd]

We are limited to data speeds that are the same as what was common on POTS lines 30 years ago. Every bit still counts here.

We have the ability to send arbitrary data, either in packet data transfers before the DV stream starts are as ancillary data in the LICH field. Feel free to add a proposal to send extended callsign attributes using one of these mechanisms.

It's also a digital voice mode -- if someone wants to note that they are mobile or via reciprocal operating authority, they can indicate that via voice. I do not believe the law requires (at least in the US) that all identifying information be transmitted digitally when using a DV mode. One can still provide this information as one would on an analog voice channel.

[SmittyHalibut]

The problem with DMR IDs is that you need an external mapping DB, not that they aren’t ASCII.

I can agree that more than 9 characters would be better if you can fit it in the frame. But bits count here, so I strongly encourage still using base40 encoding, but bringing it up to a 64bit field, instead of 48. I’d have to run the numbers again to see what that gives, but it seems reasonable.

It just consumes another 2 or 4 bytes in the headers that have to come from somewhere.

[tarxvftech]

Also such things as overloading commands on to callsign fields should be
discouraged as they create ambiguity. Commands like link and unlink should
have their own field or even packet type.

I support this.

Closing the ticket since there's no recent activity and it seems to me like the primary concerns were addressed. Please re-open if there are further thoughts!