[P25nx] Welcome

Fri Jul 27 15:00:56 EDT 2018

Sent from an iPhone 8

On Jul 27, 2018, at 2:56 PM, Jamison Judge <jamison at jamisonjudge.com> wrote:

>> 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.
> 
I wasn’t aware I was making a desperate plea for disaster. I thought it was kinda slick , actually. 

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

It solved the dynamic talkgroup problems too. New talkgroups can be built on the fly. 
> 
> 
> 
>> 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
> 
> _______________________________________________
> P25nx-interest mailing list
> P25nx-interest at lists.keekles.org
> http://lists.keekles.org/cgi-bin/mailman/listinfo/p25nx-interest