[P25nx] Welcome

[jy at xtra.co.nz]

When I say the codec is in the end point to be more precise that of course means the radio terminal not the Quantar...

> On 26 July 2018 at 16:47 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.
> 
> 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
> _______________________________________________
> P25nx-interest mailing list
> P25nx-interest at lists.keekles.org
> http://lists.keekles.org/cgi-bin/mailman/listinfo/p25nx-interest