DL5DI Hans nous explique la situation à propos de BrandMeister et les problèmes techniques provoqués par les connexions à DMRPlus ou DMR-MARC.

Hans a publié hier un billet dans le groupe Yahoo DVRPTR pour prévenir les utilisateurs et les sysops à propos des problèmes générés par BrandMeister sur le réseau. Voici le résumé et le texte source.

En outre, un groupe tente actuellement d’utiliser notre nom DMR-FRANCE ® pour créer un serveur sur BrandMeister sans maitriser le réseau et sans concertation. Nous dégageons toutes responsabilité sur les problèmes générés.

Pour résumer :

BrandMeister n’est pas compatible avec DMRPlus ni DMR-Marc. Plusieurs connexions ont été effectées sur des serveurs DCS en DMR ou DSTAR, provoquant de graves problèmes techniques.

  1. Il ne faut pas connecter plus d’une gateway par réflecteur DCS.
  2. Il ne faut pas connecter un serveur DMR Master dans un autre pays que celui assigné par le sMaster (cross-connect). En France, c’est le sMaster 208 : http://cc1.dmr-france.org/dmr/
  3. Le réseau DMRPlus est un réseau privé, basé sur l’authentification des utilisateurs avec un ID-CCS7. Les réseaux DExtra et BrandMeister ne sont pas compatibles.
  4. Pas de Gateway ni de Réflecteurs sur le slot 1 DMR.
  5. L’équipe DMRPlus et DMR-FRANCE (DR@F) recommande de ne pas connecter de serveur BM à l’infrastructure DMRPlus. Ses connexions seront immédiatement bannies du réseau.

Lorsque BM sera compatible avec DMRPlus, DMR-MARC, IrcDDB et DStar USTrust, nous pourrons annoncer les interconnexions.


Texte source du billet Yahoo Group DVRPTR (DL5DI) :

“Running Brandmeister at CCS/DCS/DMRplus”

Hi all!

I would like to prevent new rumors to be spread from Brandmeister users:

We are running a dstar-dmr-gateway from DSTAR reflector DCS001V to DMR reflector 4012.
Please note that it is not allowed to connect any other gateway to that reflector room!
This is valid for all gateway channels on the DCS/DMRplus reflector networks.

This has technical reasons and it is described clearly in the manual ever since the gateway software exists.
It is not new and has nothing to do with Brandmeiter or any other software – whoever developed it – and also not with politics.
Running more than 1 gateway on a reflector channel creates ugly loops which break the system and reduce the network performance.
Every gateway-capable software will be blocked on existing gateway channels.

Who ever runs one of our gateways should know that .

We recommend not to use BM to connect to DCS.
Users in Austria may understand best why, they experienced last week what happened.
BM running at OE9XXX-F killed DCS009 in Austria regular every 3 minutes and kicked all users out.
This was no hidden problem, it was visible on the xreflector status pages, we have got many emails, screenshots and phone calls from Austria.
We expect that tests with new interfaces are always observed carefully and are stopped immediatly in case of any issues.
But no admin took care in this case, we did not step in, it took hours until the BM connection to DCS009 was stopped.
Understand it or not, we are not willing to accept such unattended tests which cause our network systems to fail.

CCS/DCS is a private system which runs on servers worldwide and may be used free of charge.
There are thousands of clients connected to the DCS servers worldwide every day from different hard- and software.
Now we are blamed for errors on server side and missing documentation of the interfaces.
This is nonsense and unattanded software tests are ruthless in my eyes.

The DCS interface is not new, it is used since several years, implemented to many open source systems.
Most of the CCS/DCS clients are running the ircDDBGateway software which is a free open source software from Jonathan G4KLX. It works perfect and is available for Windows and different Linux platforms.

Based on many experiences like this during the las months we would very mich appreciate if tests with BM would please be done without any connectivity to CCS/DCS or DMRplus.
To my understanding of the publications on the web BM prefers XRF reflectors anyway and claims since months agains DCS. So why should it connect to DCS?

We cannot observe the DSTAR and DMR traffic continously 24/7 worldwide and cannot fix issues individually.
If admins don’t observe their tests we need to find a technical solution and block those systems automatically.

Please do us all a favour, test BM on the own network and let us agree to set up interfaces at a later time from our side.
We proved already before with ircDDB<->US-Trust and DMRplus<->DMR-MARC that we have experiences with interfacing to other networks without creating any issues. All this systems use undocumented protocols and commercial hardware which has no real official interface to connect to.

More important than the technical issues with the interfaces are the network rules which make sure that a network works properly.
The most important rules for CCS/DCS/DMRplus should be known, it is shown in our presentations on the web since we started to connect the different digital voice systems.
We pointed it out in emails several times:

– No gateways on worldwide DMR timeslot 1, only on local ts2.
Otherwise it creates loops and other issues.
This is also agreed with the DMR-MARC group.

– No reflectors on worldwide DMR timeslot 1, only on local ts2.
Otherwise it creates loops and other issues.
This is also agreed with the DMR-MARC group.

– No 2 gateways on one reflector channel.
Otherwise it creates loops and other issues.
This usually requires that a gateway may not be switched by users to different reflector rooms.

– Usage of the network has to be restricted to registered IDs (DMR/CCS7).
There are local laws on the world which require this because we do not use the amateur radio callsign on DMR.
This does not allow to set up gateways to analogue systems (without special technology on analogue radio side to transfer the own ID)

– No cross-connects between DMR-Masters, sMasters, bMasters.
DMRplus uses a hierarchical network with a strict tree structure, other than BM which uses a full meshed network.
Low traffic is more important for us than redundancy and we expect that this is accepted.

Brandmeister proved many times in the last months that it does not respect that rules (last time to be seen today morning on DCS001V, last week on DCS009, this week on MARC TS1 – which is not really our own problem).

There are people who even want to bring us to court because we are not open enough with interfaces.
Maybe it would be good to open the eyes and see what is going on technically and not politically, in rumors, in nice presentations or crazy emails.
This all has nothing to do with the quality of the Brandmeister system.
I only saw it shortly on the Hamradio and have really no reason to talk bad about it.
But it is not compatible to DCS and DMRplus.
Interfaces can be adjusted, but also the network rules need to be respected.

We are very open with that: we do not intend to change our current rules and network structure.
It is a basic requirement for the network functionality and reliability.
Other (maybe better) concepts need to interface in a really compatible way and respect the rules or have to run separate.

To show an example from the world outside of Amateur Radio how professionals do it:
You can setup a phone call from a DMR radio to the public telephone network.
It works perfect.
Neither the DMR network has to be changed for that, nor the public phone network has to be changed.
Both keep their own network rules, structures, protocols and technical requirements.
There is no need.
The gateway between the 2 systems has to make sure that it works on both sides with the appropriate network rules.

Brandmeister adapts to our interfaces, claims to behave like our systems, but in reality it uses the own network rules and features and it breaks our systems every day because the developers or admins believe that it is the better concept.
That is not a fair way and it is not acceptable for us.
A good adaption not only repects the low level of the interface, but also the higher level rules.

73 de Hans DL5DI

The following two tabs change content below.
Radioamateur depuis les années 90, j'ai commencé par faire quelques expérimentations en BLU. J'ai beaucoup appris avec le hack d'équipements de radiotéléphonie pour créer des répéteurs FM. J'ai découvert le numérique avec le P25 en 2002 à Dayton. Avec un groupe d'amis (F4ACD, F1UOT), nous avons créé l'association DR@F en 2009 pour faire évoluer la réglementation. Nous avions alors obtenu satisfaction en 2013, avec un accès pour tous les radioamateurs au numérique et aux connexions Internet.