Line 4: | Line 4: | ||
== Disclaimer == | == Disclaimer == | ||
− | This protocol should only be used for connecting repeaters/hotspots with RF directly. To connect networks/applications/terminals/analog/bridges, other protocols exist - please contact the dev team so that a good implementation can be made. We can't give support if the protocol is used for other things than connecting repeaters/hotspots with RF directly. | + | This protocol should only be used for connecting repeaters/hotspots with RF directly. To connect networks/applications/terminals/analog/bridges, other protocols exist - please contact the [https://t.me/BRANDMEISTERGENERALSUPPORT dev team] so that a good implementation can be made. We can't give support if the protocol is used for other things than connecting repeaters/hotspots with RF directly. |
== G4KLX MMDVMHost version == | == G4KLX MMDVMHost version == |
At the moment we have two versions of the Homebrew repeater protocol:
This protocol should only be used for connecting repeaters/hotspots with RF directly. To connect networks/applications/terminals/analog/bridges, other protocols exist - please contact the dev team so that a good implementation can be made. We can't give support if the protocol is used for other things than connecting repeaters/hotspots with RF directly.
This version of the homebrew repeater protocol is implemented at BrandMeister as "MMDVM Host". The protocol is very close to a version of DL5DI but has some principal changes that are not documented in that specification. Over time, changes introduced have alienated these two protocols.
https://github.com/g4klx/MMDVMHost g4klx/MMDVMHost
You can find the spec here: File:DMRplus IPSC Protocol for HB repeater.pdf This version of the homebrew repeater protocol is implemented at BrandMeister as "Homebrew Repeater"
Please note, this specification is not necessarily complete.
RPTSBKN01234567Where 01234567 is ID of repeater (hexadecimal string of 8 characters).
RPTRSSI01234567:1-120.0Where
Client could request server to interrupt current incoming call.
RPTINTR01234567:1Where
One of the targets of the Homebrew Protocol is mobile devices such as mobile phones. This kind of devices have very strong requirements for power saving (Power Management for Mobile Devices). To make access for these devices more comfortable we added support of a native activation mechanism to Homebrew Protocol. Now we can activate devices via Google's Firebase Cloud Messaging which is a native mechanism for Android devices.
To do this, the BrandMeister DMR Server supports the following new messages that may be sent by the client:
RPTIDLE01234567-393838907279:bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...Where 01234567 is the repeater ID (hexadecimal string of 8 characters) then application token ID (393838907279), deimeter (":") and the last part is the device token. We recommend to send this message several times (i.e. 3 times), and the server will respond with MSTACK
RPTWAKE01234567-393838907279:bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...Where 01234567 is the repeater ID (hexadecimal string of 8 characters) then application token ID (393838907279), deimeter (":") and the last part is the device token. Upon success the server will respond with MSTACK.
In the connection's idle state the server will send any data such as the headers of any voice calls, data calls, and CSBK (but not voice frames) via Cloud Messaging. Client applications should then go back and switch the connection to an active state to get a stream over UDP.
{ "data" : { "type" : "Homebrew Repeater", "data" : "010203040506070809..." }, "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1..." }
data/data field contains normal DMRD message of Homebrew Protocol in hexadecimal representation.
We strongly recommended to use your own application token ID. In that case please provide us your application token ID and authorisation key. Both will be hardcoded in the source code. Default application token ID is 393838907279
The main reason for this extension is support of homebrew terminal mode that should have different client UX and behaviour on the server side.
The message should be sent instead of repeater Configuration protocol message immediately after authentication.
Request of client:
TRMENT01234567:callsign:software-version
Response of server:
TRMACK01234567
01234567 is a hexadecimal ID of client
callsign is a text string of user callsign
software-version is a string to identify software and it's version
Request of client:
TRMSUB01234567:TG4321
Response of server:
TRMACK01234567
01234567 is a hexadecimal ID of client
TG4321 is a group ID
Request of client:
TRMUNS01234567:TG4321
Response of server:
TRMACK01234567
01234567 is a hexadecimal ID of client
TG4321 is a group ID
Request of client:
TRMUNS01234567:ALL
Response of server:
TRMACK01234567
01234567 is a hexadecimal ID of client
Request of client:
TRMEXL01234567:TG4321
Response of server:
TRMACK01234567
01234567 is a hexadecimal ID of client
TG4321 is a group ID (PV1234567 is a private ID)
Request of client:
TRMEXL01234567:EXIT
Response of server:
TRMACK01234567
01234567 is a hexadecimal ID of client
Slot flag should be unset.
At the moment we have two versions of the Homebrew repeater protocol:
This protocol should only be used for connecting repeaters/hotspots with RF directly. To connect networks/applications/terminals/analog/bridges, other protocols exist - please contact the dev team so that a good implementation can be made. We can't give support if the protocol is used for other things than connecting repeaters/hotspots with RF directly.
This version of the homebrew repeater protocol is implemented at BrandMeister as "MMDVM Host". The protocol is very close to a version of DL5DI but has some principal changes that are not documented in that specification. Over time, changes introduced have alienated these two protocols.
https://github.com/g4klx/MMDVMHost g4klx/MMDVMHost
You can find the spec here: File:DMRplus IPSC Protocol for HB repeater.pdf This version of the homebrew repeater protocol is implemented at BrandMeister as "Homebrew Repeater"
Please note, this specification is not necessarily complete.
RPTSBKN01234567Where 01234567 is ID of repeater (hexadecimal string of 8 characters).
RPTRSSI01234567:1-120.0Where
Client could request server to interrupt current incoming call.
RPTINTR01234567:1Where
One of the targets of the Homebrew Protocol is mobile devices such as mobile phones. This kind of devices have very strong requirements for power saving (Power Management for Mobile Devices). To make access for these devices more comfortable we added support of a native activation mechanism to Homebrew Protocol. Now we can activate devices via Google's Firebase Cloud Messaging which is a native mechanism for Android devices.
To do this, the BrandMeister DMR Server supports the following new messages that may be sent by the client:
RPTIDLE01234567-393838907279:bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...Where 01234567 is the repeater ID (hexadecimal string of 8 characters) then application token ID (393838907279), deimeter (":") and the last part is the device token. We recommend to send this message several times (i.e. 3 times), and the server will respond with MSTACK
RPTWAKE01234567-393838907279:bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...Where 01234567 is the repeater ID (hexadecimal string of 8 characters) then application token ID (393838907279), deimeter (":") and the last part is the device token. Upon success the server will respond with MSTACK.
In the connection's idle state the server will send any data such as the headers of any voice calls, data calls, and CSBK (but not voice frames) via Cloud Messaging. Client applications should then go back and switch the connection to an active state to get a stream over UDP.
{ "data" : { "type" : "Homebrew Repeater", "data" : "010203040506070809..." }, "to" : "bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1..." }
data/data field contains normal DMRD message of Homebrew Protocol in hexadecimal representation.
We strongly recommended to use your own application token ID. In that case please provide us your application token ID and authorisation key. Both will be hardcoded in the source code. Default application token ID is 393838907279
The main reason for this extension is support of homebrew terminal mode that should have different client UX and behaviour on the server side.
The message should be sent instead of repeater Configuration protocol message immediately after authentication.
Request of client:
TRMENT01234567:callsign:software-version
Response of server:
TRMACK01234567
01234567 is a hexadecimal ID of client
callsign is a text string of user callsign
software-version is a string to identify software and it's version
Request of client:
TRMSUB01234567:TG4321
Response of server:
TRMACK01234567
01234567 is a hexadecimal ID of client
TG4321 is a group ID
Request of client:
TRMUNS01234567:TG4321
Response of server:
TRMACK01234567
01234567 is a hexadecimal ID of client
TG4321 is a group ID
Request of client:
TRMUNS01234567:ALL
Response of server:
TRMACK01234567
01234567 is a hexadecimal ID of client
Request of client:
TRMEXL01234567:TG4321
Response of server:
TRMACK01234567
01234567 is a hexadecimal ID of client
TG4321 is a group ID (PV1234567 is a private ID)
Request of client:
TRMEXL01234567:EXIT
Response of server:
TRMACK01234567
01234567 is a hexadecimal ID of client
Slot flag should be unset.