[P25nx] Welcome

[jy at xtra.co.nz]

Hi Pierre,

The DSP farm will not know how to mix frames of type transparent so we need a multicast strategy that does not involve the DSP.  Equally we probably want to avoid a voter instance.

73, John ZL4JY


> On 26 July 2018 at 17:03 bernardp92 at gmail.com wrote:
> 
> 
> Interesting !
> 
> I was also looking at the hoot & holler feature in Cisco for RTP multicast to connect analogue radio and IP phone.
> 
> But this is linked to a dsp farm hw inserted into the router. The transparent mode is interresting to have the codec at the end. Will it be possible ?
> 
> Pierre F1shs
> Paris
> Sent from my IPhone
> 
> > Le 26 juil. 2018 à 06:47, jy at xtra.co.nz a écrit :
> > 
> > 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
> _______________________________________________
> P25nx-interest mailing list
> P25nx-interest at lists.keekles.org
> http://lists.keekles.org/cgi-bin/mailman/listinfo/p25nx-interest