[App_rpt-users] Nodes on same server linked, but not repeating audio?

[Bryan Fields]

On 11/3/17 4:45 AM, Chuck Henderson wrote:
> Maybe it should but I don't think it will.
> The problem with the servers all thinking that their public port is 4569 is
> that then the registration system will advertise them with the wrong port
> unless other steps are taken to modify the registration info.  At least
> that is what I ran into when I first tried to do it years ago like you
> suggested.  I found the simple fix was to have each server on a different
> port, same as Andy is saying.  Maybe now the registration servers are newer
> and improved and they pick up NATed ports during registration.  I don't
> know.

It's set in the server config in the portal.  But yea, I'd tend to agree from
an operational perspective, just keep the UDP ports the same on the inside and
outside.

> I am a dinosaur, I know. CCIE2285  I helped write some of the code that
> runs in Cisco routers.  I greatly improved the IPV4 NAT code in Cisco
> routers (in the beginning) and really made it work well and scale better.
> Most of the advanced NAT features that I designed are still in all Cisco
> routers and L3 switches but are not used because almost no one knows how to
> configure them. So I have to disagree about NAT being evil.  It is
> wonderful if you know how to configure it.

ALU NRSexpert here, all my other certs expired long ago.  Though I did
interview a guy in his CCIE bomber jacket a few months back ;)  Cisco's
certainly diluted their certs value, it's a profit center now.  I do know the
difference between a route-map and an ACL for NAT overload in IOS classic,
FWIW.  I even had a bit of NAT with a VRF looped back to allow mapping TCP
port on one server to a port on a VRF loopback.  It's disgusting to even
recall it.

NAT breaks the internets goal of end-to-end connectivity.  It's evil, and I'll
proclaim it loudly.  Now it can be useful for certain things, but I'd rather
have globally unique addresses in the first place.


> I watched the video.  Sorry, there currently is no IPV6 in the voter board
> or the RTCM but they are still very useful.  Maybe you can write the IPV6
> for them.

I'd love to, but I think we'd need to consider separating the IP/mgmt from the
real time parts of the RTCM.  We'd also need to get on a newer version of
asterisk too.  I think we'd all be in agreement about moving to a more recent
version.  I got down this rat hole from time to time with a friend of mine on
how to improve the RTCM.


> I am aware of a couple of bugs in the app_rpt.c that were never fixed by
> Jim despite me identifying them and what was causing them.
> Yours could be related and I will look for my notes about what I had found
> and see if those parts of the code are still the same.
> One of the bugs I had tracked down was a bug that under specific situations
> would send all transmit audio out over the links including local only audio
> like IDs and tones. Apparently, I was the only one who experienced it even
> though Jim could reproduce it with my info.  As I remember he gave me the  "
> locallist" and "locallinknodes" commands to work around the bug.  That was
> too long ago and I don't still have the configurations that needed that and
> I don't see any documentation for them so I will have to dig through notes
> from long ago to re-find that info.  As I recall, I think it was a sequence
> of keydowns back and forth between the linked local nodes aligning with an
> ID that would induce the strange problems reliably every time.  Unlinking
> the permalinks and re-linking would fix it until the next time.  Now I have
> separate computers for each node so it isn't an issue for me now like it
> was back then.
> While typing this little pieces of memory are coming back to me.  Maybe
> after my regeneration cycle tonight I will remember it all.  Maybe I have
> jogged someone else's memory who can fix this before I can remember it.

If you can document it or publish it, I'm sure we can get it fixed.  I'm
almost certain I'm seeing some buffer overflow or similar bug here.

73
-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net