HBlink@DVSwitch.groups.io | Private Call HBlink to BM via OBP

Roby IV3JDV

#1994

No,
if HB does not know where to route the call, ONLY the first time, it sends the call to all the MASTER included in [unit].
If the user answers, from that moment on, the calls are sent ONLY to the masters involved until the TTL expires.
Absurdly, HB can find a user, even if he has never been "heard" by the servers

Roby

Giacomo De Angelis

#1993

>> If you have a single server the problem doesn't exist.

The problem exists in the current HB, the PV call reaches all the repeaters.

In a distributed network the PV call reaches all the Masters (as happens for group calls) but the single master delivers it to the repeater where it was heard, as with sms. This is how smartly drawn BM.

What you want and can only be done with a new HB (new drawing and new writing)

73

Show quoted text

Il giorno mar 27 ott 2020 alle ore 11:20 Roby IV3JDV <roberto@...> ha scritto:

If you have a single server the problem doesn't exist.
In a "distributed" network such as HB, or in the case of multiple servers, you need the "lastheard database" to be shared in real time with all servers otherwise not everyone knows where to route the call. I don't know if there is a "user TTL" of BM servers, but I would like to understand how does it route a call to a user if it has never been heard.
From this point of view, the idea of HB is good, it must certainly be improved

Roby

Roby IV3JDV

#1992

If you have a single server the problem doesn't exist.
In a "distributed" network such as HB, or in the case of multiple servers, you need the "lastheard database" to be shared in real time with all servers otherwise not everyone knows where to route the call. I don't know if there is a "user TTL" of BM servers, but I would like to understand how does it route a call to a user if it has never been heard.
From this point of view, the idea of HB is good, it must certainly be improved

Roby

Giacomo De Angelis

#1991

You do not need a common db. The pv call coming from OBP must be handled by each individual master, BM has this function. It is not important the slot for OBP and the master who needs to know on which repeater and slot should be forwarded. HB was not designed with dynamic routing and so there are many implementations to do. The solution found on HB is deleterious to the repeater network, the PV call must be sent exclusively to the repeater where ID was heard.

Those who want to race must use ferrari (BM), HB is a Fiat Panda -:). Unfortunately HB was designed to do little things.

73 IU7MNA

Show quoted text

Il giorno mar 27 ott 2020 alle ore 09:06 Roby IV3JDV <roberto@...> ha scritto:

Unfortunately, HBLink does not store all received IDs and therefore, in case of a private call, it does not know where to send it. At the moment it works like this: on the first call hblink sends the call to all the hosts defined in [unit] some kind of broadcast. if the answer happens, memorize the ”return path” if I'm not mistaken for a minute. from now on, the private call will be routed only between the hosts involved. Everything is very simple within the same server but, if the flow has to pass through OBP, things get complicated. OBP expects all traffic on the TS1 and this greatly limits the functioning of the PCs. Moreover, the lack of a common database between servers makes everything extremely critical and not very functional.

Roby

Roby IV3JDV

#1990

Unfortunately, HBLink does not store all received IDs and therefore, in case of a private call, it does not know where to send it. At the moment it works like this: on the first call hblink sends the call to all the hosts defined in [unit] some kind of broadcast. if the answer happens, memorize the ”return path” if I'm not mistaken for a minute. from now on, the private call will be routed only between the hosts involved. Everything is very simple within the same server but, if the flow has to pass through OBP, things get complicated. OBP expects all traffic on the TS1 and this greatly limits the functioning of the PCs. Moreover, the lack of a common database between servers makes everything extremely critical and not very functional.

Roby

Charly

#1987

Si, creo que si, están con mucho movimiento en el tema estoy seguro que pronto lo sacaran.

Yo sigo con el tema de que no puedo enlazar con OBP de un Server a Otro, curiosamente si doy PTT en el TG9 en el server donde estoy enlazado contigo si jala, pero si le doy PTT en el TG9 en el otro server sin haber hecho primero el PTT en el otro no funciona, me manda un error.

Ahorita que me desocupe lo voy a subir al foro.

Saludos.

Libre de virus. www.avast.com

El lun., 26 de oct. de 2020 a la(s) 16:07, Alejandro Pereida via groups.io (xe2_bss=yahoo.com@groups.io) escribió:

Show quoted text

Pos si,no jala, a ver ya' que me familiarize mas con Python y el proceso de las llamadas de DMR a ver si cascareo, no va' a estar tan pelada, pero no hay peor lucha que la que no se hace o a lo mejor alguien lo implementa en poco tiempo.

On Monday, October 26, 2020, 3:21:34 PM PDT, Randy AA6RH <aa6rh@...> wrote:

Yes, there needs to be some kind of unit-to-unit call registry that ensures a return call goes back over the original time slot. That would need to be swept and managed so that old private calls are cleaned up if (for whatever reason) the return call never comes.

But realistically, it needs to be something like lastheard, inasmuch as the last time your ID is seen on the HBLink side of the network, HBLink should know where to send a unit-to-unit call to your ID. Otherwise, it should send it to TS1 (IMO).

I remember Cort struggling with this a bit, and the solution he came up with was a compromise. I'll have to go back into the forum archives to see if I can find it.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

Alejandro Pereida

#1986

Pos si,no jala, a ver ya' que me familiarize mas con Python y el proceso de las llamadas de DMR a ver si cascareo, no va' a estar tan pelada, pero no hay peor lucha que la que no se hace o a lo mejor alguien lo implementa en poco tiempo.

On Monday, October 26, 2020, 3:21:34 PM PDT, Randy AA6RH <aa6rh@...> wrote:

Yes, there needs to be some kind of unit-to-unit call registry that ensures a return call goes back over the original time slot. That would need to be swept and managed so that old private calls are cleaned up if (for whatever reason) the return call never comes.

But realistically, it needs to be something like lastheard, inasmuch as the last time your ID is seen on the HBLink side of the network, HBLink should know where to send a unit-to-unit call to your ID. Otherwise, it should send it to TS1 (IMO).

I remember Cort struggling with this a bit, and the solution he came up with was a compromise. I'll have to go back into the forum archives to see if I can find it.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

Randy AA6RH

#1983

Yes, there needs to be some kind of unit-to-unit call registry that ensures a return call goes back over the original time slot. That would need to be swept and managed so that old private calls are cleaned up if (for whatever reason) the return call never comes.

But realistically, it needs to be something like lastheard, inasmuch as the last time your ID is seen on the HBLink side of the network, HBLink should know where to send a unit-to-unit call to your ID. Otherwise, it should send it to TS1 (IMO).

I remember Cort struggling with this a bit, and the solution he came up with was a compromise. I'll have to go back into the forum archives to see if I can find it.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

Dan K2IE

#1980

I'm using the main branch. I'm aware of the OBP option to use both slots, but that is not supported by BM so I can't use it in this case.

So here's what I got working...private calls do traverve the OBP bridge to BM. However, when the return call comes, it goes out on TS1 only, even if I originally made the call on TS2. So if I put the radio in dual slot mode I can hear the return call. Not ideal, but it worked to validate the flow.

Seems like we need a method for HBlink to know theat the PC needs to be forwarded back to the originating timeslot, rather than to change how OBP operates. Since HBlink already knows that if I send the traffic on TS 2 it still needs to go out via OBP on TS1, the reverse is hopefully not impossible to solve for someone who understands the flow.

I also noticed something odd about PC functionality if XLXPEERing is enabled, but I'll start a new thread for that since it is a different issue.

73

Roby IV3JDV

#1979

The "private call-dev" branch uses a NON STANDARD version of the OpenBridge protocol which provides the "timeslot transport" in order to create the "return circuit".

I don't think, at the moment, that it works out of the HBLink world

Roby

Dan K2IE

#1977

I have not yet successfully received a private call sent from HBlink to BM. The call is going out via the OBP link according to hblink.log.

Should this work? If so, someone who knows this works for them and would volunteer to send/receive a PC to/from me via BM that would be appeciated.

Thanks.