>> When a user call sign routes into a repeater does that repeater update the 
>> users table with their current information?

YES (G2).  We tested this with zone ("slash") routing when G2 first came out, 
and it does update the destination gateway with the transmitting user's current 
information if he is on a different gateway.  

> AFAIK, the ONLY updating that occurs is to the Trust Server and then 
> replicated out. So one repeater will not update another repeater system.

Yes, but with G2 a called gateway immediately updates itself with the caller's 
gateway information so folks on the called gateway can callsign route back to 
the caller immediately.
 
> The only exception, with the latest gateway software, is that if you move 
> between modules on the same system, the local system will redirect the call 
> to the module that you are on.(*)

This is a critical part, btw, to make it work.  NU5D and I tested this in 
August 2008.  I should draw a picture, but let me try to explain.

The setup was:

1) I had pgadmin3 running on a Fedora box. I was logged into the dstar_global 
databases on K5CTX and W5HAT, and I watched the sync_mng table entry for NU5D 
on both machines, each in it's own x-window. I refreshed one view, then the 
other, back and forth every few seconds, so I could see changes within a second 
or two on each gateway.

2) NU5D was within range of both K5CTX and W5HAT. He always transmited on the B 
band, and he zone routed to the other machine. Thus, when transmitting on 
W5HAT^^B, he routed to /K5CTX^B.

3) Before we started, both sync_mng tables showed him homed on K5CTX^^B.

4) With both gateways showing him homed to K5CTX as above, he transmited on 
W5HAT^^B with UR=/K5CTX^B. As fast as I could click refresh on the pgadmin3 
window, sync_mng on W5HAT now showed him homed to W5HAT^^B (immediate update). 
My next click updated the x-window showing sync_mng on K5CTX (destination 
gateway) which now shows him homed to W5HAT^^A (partial immediate update) -- 
note, this is the correct gateway, but he is actually on the B module, not A.  
But this doesn't matter!!

5) This is where Ed's point above - "if you move between modules on the same 
system, the local system will redirect the call to the module that you are on" 
comes to the rescue.  Put another way, if you route to the correct gateway but 
wrong module, the recipient gateway will still send the stream to the correct 
module for a user known to be on that gateway.  K5CTX show him homed to 
W5HAT^^A when he is really on W5HAT^^B because the header K5CTX received does 
not tell K5CTX which module he is on, but K5CTX only has to route to W5HAT and 
W5HAT will correct the band module before transmitting the stream to RF!  

6) Later we did the same test with callsign routing, and everything worked the 
same.  So if you are a mobile user, the folks you call on other gateways will 
be able to immediately route back to you.  Folks on other gateways won't be 
able to route to you until their gateway has been updated by the trust server, 
however.  Or put yet another way, you as a mobile user can update any gateway 
as to your current homed gateway by zone ("slash") routing a header to the 
gateway you wish to immediately update.  Then any user on that gateway can 
callsign route back to you.

73 -- John


Reply via email to