[P25nx] Welcome

[jy at xtra.co.nz]

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.

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.

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.

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.

Not a fully baked idea yet and I've not tried any part of this, so it's just my 2 cents worth for discussion.

73, John ZL4JY

 

> On 26 July 2018 at 13:30 Bryan Fields <Bryan at bryanfields.net> wrote:
> 
> 
> On 7/25/18 1:29 AM, Dan Woodie wrote:
> > Bryan,
> > 
> > What prompted the switch from Google Groups?  As far as I could tell there
> > was no issue with the way it was working.  
> 
> It was tied to David's personal account, and it's not possible to move that.
> Google also prevents anyone from downloading the archives.  There is the total
> lack of any support with google, it's a best effort service.  If it goes
> sideways, you don't have any options.
> 
> > The way I see it you just took a
> > struggling project and removed access to the archives of valuable
> > information and switched to a mail list with a more archaic interface.  
> 
> How so, the archives are still on google groups if you want to search them.
> As the group on google was set to private, it wasn't indexed unless you were
> signed in and in their "interface".
> 
> Perhaps the largest issue with google groups is the lack of inserting a ID in
> the subject and the poor support of threading.
> 
> > I
> > use Google Groups all the time and have had no issues whatsoever.  Now, if
> > you were switching from Yahoo Groups I might support the move.  I for one
> > vote for a switch back to the Google Group.
> 
> Then post there.
> > I am considering bringing the K8BIG repeaters back online as V2 but have
> > been a bit concerned about the stability issues - so I haven't wasted my
> > time - which I don't have much of these days.  
> 
> Then don't waste ours.
> 
> > Regarding the dropped audio packets on the network - we deal with that at
> > work frequently when customers don't purchase their leased lines/MPLS
> > Circuits with appropriate LoS agreements.  
> 
> QoS?
> 
> > The P25 data streams can deal
> > with some latency and packet loss 
> 
> They cannot deal with any packet loss.  In the current system, every 20 ms
> frame is shoved onto the network, and due to the p25 super frame format,
> losing a couple frames can nuke the larger super frame.  There is no error
> handling or counters to know where or if drops are happening.
> 
> > but high-jitter, high latency networks
> > such as the internet are not ideal.  I suspect most of the issues are due
> > to this.  If a carrier's network gets busy it just dumps the traffic into a
> > "Best Effort" pool and sends it when the bandwidth is available - if the
> > bandwidth doesn't become available within a specified time window the
> > packets are simply dropped.  
> 
> The internet is all best effort.  Once I hit a peering point my DSCP is going
> to be ignored or rewritten to CS0.  Given the propensity of carriers using
> unbuffered chipsets in the backbone now, even a lightly loaded link can drop
> packets due to bursts.
> 
> > Other than adding buffering of some sort I
> > don't know if there is a good solution to this.  
> 
> My thoughts were to have some counters and options for multiple packets.  the
> bitstream is like 6.7 kbit/s, just elect to receive 2 packets, and discard
> one.  It's basically cheap FEC, and the difference between 6.7 and 13kbit/s is
> nothing on today's internet.
> 
> At one time I was working with a friend on this in Go, but not much has
> happened with it due to work.
> -- 
> 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