[P25nx] Welcome

Thu Jul 26 01:03:26 EDT 2018

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