[P25nx] Welcome

[Bryan Fields]

On 7/26/18 12:47 AM, jy at xtra.co.nz wrote:
> Hi Bryan,
> 
> Thank you for breathing fresh life into this group.
> 
> As you I'm sure you know the issue of jitter has rather plagued P25
> transmission over the internet well before the advent of P25NX.
> 
> I've spent some time looking at the jitter issue and at my urging Dave's
> P25NX V1 dashboard did have a jitter meter of sorts to allow jitter to be
> examined.  FWIW my impression is that the audio from a Quantar locally
> connected to a voter that in turn is receiving packets form the internet
> via the original Cisco STUN process sounds better than the same stream
> connected directly to the Quantar.
> 
> One of the P25NX V2 goals was to move away from the STUN TCP style
> connection to UDP but I think that is only half of the solution.  Similarly
> writing code to implement a jitter buffer for STUN based on the Motorola
> V.24 transport has issues because there is not a one-to-one relationship
> between the V.24 records and and STUN frames.

Well that's the issue is having to use a cisco.  It's a cheap off the shelf
sync serial HDLC to IP converter.  It's not designed for any of this, hell
STUN isn't even a defined protocol.

Our first work was doing programed IO at 9600 bps, and we just couldn't keep
up, it needed a dedicated hardware.  Luckily Juan Carlos XE1F, was able to
code up a sync to async HDLC in a PIC16F887, and I got a prototype of this
working.  This converts the sync HDLC to a regular serial port at 9600 bps.

This needs more testing.

> A possible line of attack may involved taking the V.24 stream and then
> packing the IMBE records one by one into RTP frames and using the Cisco
> router's built-in RTP jitter buffer features.  This addresses both UDP
> transport and the necessary timestamps for successful de-jitter
> processing.

So we did get something like this going.  It talks STUN to a cisco and
completely rebuilds the frames that the Quantar expects.  This can take a raw
IMBE data, and publish it to the quantar and ensure the Reed Solomon FEC is
setup properly, along with all the other flags and bits needed.  We can do the
same in reverse.  This is all written in Go.

RTP may be an option for this, but much of the protocol would need to be
engineered for this application.

> How might this work?  There is no RTP payload type for Motorola V.24
> encoded IMBE.  AFAIK there is no RTP type for IMBE but there is a Cisco
> support payload type of 'transparent' which operates with the assumption
> that the codec is in the endpoint (i.e. the Quantar or DIU).
> 
> So my proposal is that Motorola V.24 is converted to RTP with the IMBE
> records packed 1:1 into 20ms RTP frames of codec type transparent then
> transported by Cisco over the internet as RTP.  The router's jitter buffer
> will de-jitter the RTP packets based on the RTP timestamp.  The de-jittered
> frames then needed to be converted back to V.24 HDLC frames for the
> connected Quantar.

20 ms frames is a horrible waste of bandwidth, and it hard on routers.  A
better idea was taking 180 or 360 ms of audio (9 or 18 frames of p25), adding
the headers and handling to it and then sending that out.  This is 100 or 200
bytes of data, plus overhead, it's still under 512 bytes of the IPv4 minMTU.

Worst case you would have 360 ms of delay through the network, and this really
isn't an issue for hams.  Now the cool thing is you can send two packets with
sequence numbers and have no need for FEC.  If one drops, you get the other,
and 360 ms of audio with headers is about 400 bytes.  This is 8kbit/s on the
wire.

If we looks at 20 ms frames, we have to pad them out to 64 bytes (minimum
packet size), and have 50 of them per second, 64 bytes * 50 frames/s * 8
bits/byte = 25.6kbit/s.  And it's much more work to route/process 50 packets
vs less than 3.

> How might this work in practice?  We connect the V.24 to the Cisco router
> using the classic WIC-1 or similar interface.  We have to accept that the
> router only knowns how to encapsulate HDLC as STUN so this needs to be spat
> out of an Ethernet port to a Raspberry Pi or similar (P25NX V2 style).  The
> Pi or other external box builds a properly formatted stream to send back to
> the router on the same Ethernet port to the far end destination.  The
> topology could be an established RTP point-to-point connection to something
> like an AstroTAC voter (or a PC emulation of that) or a point-to-multipoint
> connection (Cisco uses the language 'hoot and holler' for this) via
> multicast much as in V2.

Oh dear god, don't let cisco do multicast, they suck total ass doing it.

What I propose is to have a core network of servers/VM's, 4 to 8 world wide.
These run linux and have GRE tunnels between them with OSPF for unicast and
MOSPF/PIM SM for multicast.  They are assumed to have a solid connections
between them as they are at datacenters.

Running on each of these Linux hosts facing the users is a unicast to
multicast daemon.  This will accept a connection from a repeater, auth it,
negotiate it (1 packet or 2 for voice), keep state of talkgroups in use
(pruning), handle forwarding/CAC if overloaded, and translations.

Basically my repeater client will connect up, via UDP over IPv4/6 to the
server, auth and negotiate if I'd like 1 or 2 copies of every frame and what
talk groups I want.  The server will convert my IPv4 unicast into IPv6
multicast on the backend.  Linux routing will forward these frames reliability
and track loss at each hop between the servers.

This makes the server side able to be robust and simple in it's process, with
most heavy lifting done on the client.  In testing this I was about to process
about 20k pps across a test network of 6 RPi 3's emulation this "core".  It
would be easy to expand this network too, and using IPv6 multicast makes it
very easy to map 65k talk groups into the IP space; much easier than IPv4.
Since this removes multicast from the clients, it will even work behind NAT.

The server side would fail over in the event of a server going down, you'd
just connect to the backup.  With a common interface, we could even write a
translator from MMDVM to it, or even YSF which uses the same IMBE codec in
wide mode (blasphemy, no?).  This would have the distinct advantage over the
the mmdvm reflectors that simply map a talk group to one server.  If WW server
is down, no one can talk.  Granted its a bit more complex too.

Much of the client is working and coded in Go.  If you know Go and want to get
involved let me know, I'm mostly on the protocol design side, coding is beyond
me.  We've all been busy with work/travel and the process is on the back burner.


-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net