DMRlink

This code actually works. If you stumbled across the project, this is what you most want to know: It's not a complete application, yet, but it does actually work and run without messing up your IPSC network! If you download it and try it, you shouldn't be disappointed like I was with every online repo I found that was supposed to be an IPSC client. Pay attention to requirements, there are several python modules needed, but none are esoteric.

What does it to today? It will connect to mulitple IPSC networks as a peer and maintain those relationships. As of the current version, it can now bridge Group Voice calls from one IPSC to another.

##PROJECT: DMR Repeater Internet Linking. PURPOSE: Troubleshooting IPSC performance issues/possibly building an application gateway to extend IPSC beyond 15 repeaters. IMPACT: Potential concern from Motorla Solutions, as IPSC is a proprietary
METHOD: Reverse engineering by pattern matching and process of elimination

PROPERTY:
This work represents the author's interpretation of the Motorola(tm) MOTOTRBO(tm) IPSC protocol. It is intended for academic purposes and not for commercial gain. It is not guaranteed to work, or be useful in any way, though it is intended to help IPSC users better understand, and thus maintain and operate, IPSC networks. This work is not affiliated with Motorola Solutions(tm), Inc. in any way. Motorola, Motorola Solutions, MOTOTRBO, ISPC and other terms in this document are registered trademarks of Motorola Solutions, Inc. Other registered trademark terms may be used. These are owned and held by their respective owners.

PRE-REQUISITE KNOWLEDGE:
This document assumes the reader is familiar with the concepts presented in the Motorola Solutions(tm), Inc. MOTOTRBO(tm) Systems Planner.

CONVENTIONS USED:
When communications exchanges are described, the symbols "->" and "<-" are used to denote the direction of the communcation. For example, "PEER -> MASTER" indicates communcation from the peer to the master. For each exchange outlined, the initiator of the particular communication will be on the left for the duration of the particular item being illustrated.

###CONNECTION ESTABLISHMENT AND MAINTENANCE

CORE CONCEPTS:
The IPSC system contains, essentially, two types of nodes: Master and Peer. Each IPSC network has exactly one master device and zero or more peers, recommended not to exceed 15. IPSC nodes may be a number of types of systems, such as repeaters, dispatch consoles, application software, etc. For example, the Motorola RDAC application acts as a peer in the IPSC network, though it doesn't operate as a repeater. The IPSC protocol supports many possible node types, and only a few have been identified. This document currently only explores repeaters - both Master and Peer, and their roles in the IPSC network.

All IPSC communication is via UDP, and only the master needs a static IP address. Masters will operate behind NATs. A single UDP port, specified in programming the IPSC master device must be mapped through any NAT/stateful firewalls for the master, while peers require no special treatment.

All nodes in an IPSC network maintain communication with each other at all times. The role of the master is merely to coordinate the joining of new nodes to the IPSC network. A functional IPSC network will continue without its master, as long as no new nodes need to join (or existing nodes need to re-join after a communications outage, etc.) This is one of the most important core concepts in IPSC, as it is central to the NAT traversal AND tracking of active peers.

Each peer will send keep-alives to each other peer in the IPSC network at an interval specified in the devices "firewall open timer". The elegantly simple, yet effective approach of IPSC, uses this keep-alive to both open, and keep open stateful firewall and NAT translations between peers. Since each device handles all communications from a single UDP port, when a device sends a keep-alive or a registration request to another device, the source-destination address/port tuple for that communication is opened through stateful devices. The only requirement to maintain communication is that this timer be shorter than the UDP session timeout of network control elements (firewalls, packet shapers, NATs, etc.) Moreover, it does NOT appear that all devices in the IPSC network require the same setting for this. Each device would appear to maintain its own set timing without interference from different interval settings on other nodes in the IPSC.

KNOWN IPSC PACKET TYPES:
The following sections of this document will include various packet types. This is a list of currently known types and their meanings. Note: The names are arbitrarily chosen with the intention of being descriptive, and each is defined by what they've been "observed" to do in the wild.

CALL_CTL_1                = 0x61        |
CALL_CTL_2                = 0x62        | Call control messages, exact use unknown
CALL_CTL_3                = 0x63        |	
XCMP_XNL         		  = 0x70		Control protocol messages
GROUP_VOICE      		  = 0x80		This is a group voice call
PVT_VOICE                 = 0x81        This is a private voice call
GROUP_DATA       		  = 0x83		This is a group data call
PVT_DATA         		  = 0x84		This is a private data call
RPT_WAKE_UP               = 0x85        Wakes up all repeaters on the IPSC
MASTER_REG_REQ     		  = 0x90		Request registration with master (from peer, to master)
MASTER_REG_REPLY          = 0x91		Master registration request reply (from master, to peer)
PEER_LIST_REQ    		  = 0x92		Request peer list from master
PEER_LIST_REPLY 	 	  = 0x93		Master peer list reply
PEER_REG_REQ              = 0x94		Peer registration request
PEER_REG_REPLY            = 0x95		Peer registration response
MASTER_ALIVE_REQ          = 0x96		Master keep alive request (to master)
MASTER_ALIVE_REPLY        = 0x97		Master keep alive reply (from master)
PEER_ALIVE_REQ            = 0x98		Peer keep alive request (to peer)
PEER_ALIVE_REPLY          = 0x99        Peer keep alive reply (from peer)
DE_REG_REQ                = 0x9a        De-registraiton request (to master or all?)
DE_REG_REPLY              = 0x9b        De-registration reply (from master or all?)

AUTHENTICATION:
Most IPSC networks will be operated as "authenticated". This means that a key is used to create a digest of the packets exchanged in order to authenticate them. Each node in the IPSC network must have the authentication key programmed in order for the mechanism to work. The process is based on the SHA-1 digest protocol, where the "key" is a 20 byte hexadecimal string (if a shorter key is programmed, leading zeros are used to create a 20 byte key). The IPSC payload and the key are used to create the digest, of which only the most significant 10 bytes are used (the last 10 are truncated). This digest is appended to the end of the IPSC payload before transmission. An example is illustrated below:

IPSC Registration Packet		Digest	
90000000016a000080dc04030400	b0ec45f4c3f8fb0c0b1d

CONNECTION CREATION AND MAINTENANCE:
The IPSC network truly "forms" when the first peer registers with the master. All peers register with the master in the same way, with a slight variation from the first peer. Below is a descirption of the process and states in creating a connection, as a peer, and maitaining it.

There are various states, timers and counters associated with each. When peers or the master send us requests, we should answer them immediatley. Our own communcation with them is timed, and may share the same timer. Counter values should be the same for every master and peer in an IPSC. They don't have to be, but that is what mother M does, and it saves a lot of resources.

COMMUNICATION WITH MASTER: The following illustrates the communication that a peer (us, for example) has with the master. The peer must register, then send keep-alives at an arbitrary interval (usually 5 - 30 seconds). If more than some arbitrary number of keep-alives are missed, we should return to the beginning and attempt to register again -- but do NOT elimiate the peers list, as peers may still be active. The only additional communcation with the master is if the master sends an unsolicited peer list. In this case, we should update our peer list as appropriate and continue.

								  +-----------------+
								  |Send Registration|
	+---------------------------->|Request To Master|<-------------+
	|                             +--------+--------+              |
	|                                      |                       |
	|                                      v                       |
	|                               +--------------+         +-----+------+
	|                               |Did The Master|   NO    |Wait FW Open|
	|                               |  Respond ?   +-------->|   Timer    |
	|                               +----+-----+---+         +------------+
	|                                    |     |
	|                                    | YES |
	|   +-------------+                  v     |
	|   |Add 1 To Keep|     +----------------+ |             +-------------+
	|   | Alive Missed|     |Send Master Keep| |             |Is Peer Count|
	|   |   Counter   +---->|  Alive Request | +------------>|     > 1 ?   |
	|   +-------------+     +-------+--------+               +------+------+
	|         ^                   |         ^                       | YES
 YES|         | NO                v         |                       v
+---+---------+--+      +------------+      |               +-----------------+
| Is The Missed  |      |Wait FW Open|      |               |Request Peer List|
|   Keep-Alive   |      |   Timer    |      |               |   From Master   |<-----+
|Count Exceeded ?|      +-----+------+      |               +----