[P25nx] Welcome

Fri Jul 27 14:56:00 EDT 2018

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

THANK YOU…… Using cisco’s gre multipoint for this type of traffic is also a desperate plea for disaster.

> Our first work was doing programed IO at 9600 bps, and we just couldn't keep
> up

Interesting. Out of curiosity, was this using Go? I’ve never tried high-level synchronous bit banging in practice, but until I read this, my gut would have said that rate would be no problem.

> 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.

I think it’s worth weighing the cost/benefit of a multicast infrastructure at all. Is the promise of theoretical "infinite scalability” worth all the complexity that’s introduced? From a pragmatic, here-and-now standpoint, we have a relatively small number of spokes that may very well naturally have very little path overlap anyway (ie an advanced multicast topology might end up acting as a defacto multiple-unicast anyway). Just a thought.

> On Jul 26, 2018, at 12:59 AM, Bryan Fields <Bryan at bryanfields.net> wrote:
> 
> 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
> _______________________________________________
> P25nx-interest mailing list
> P25nx-interest at lists.keekles.org
> http://lists.keekles.org/cgi-bin/mailman/listinfo/p25nx-interest