RF Id <-> Network Id Translation

[HegrJan]

Solved #57 by adding the IdRewrite=RFId,NetId rule to the network configuration section. Multiple such rules can be specified for one network. Matching source Id is rewritten before writing to the network, incoming private calls to the Network Id are rewritten to the RF Id.

[g4klx]

I’m still not happy with the concept but the code is fine. I’ll add it and see if any abuse of it is reported. Thanks for the contribution.

[d51r3verse]

I agree with g4klx, seems abusing features. Also you implemented so complicated... You can just change orders every SrcRewrite first, then TGRewrite. That's all. No need to add bunch of codes... and I think you break consistency( Final level rewrites only RFRewrites, and NetRewrites )

@HegrJan Here is suggested mine #74 implementations

RewriteType -> RewriteSrc -> RewritePC -> RewriteTG -> PassAllTG -> PassAllPC

What for?: For keep super simple base TGRewrites[1-999999:11000001-11999999],[1-999999:12000001-12999999] to every 5 networks, Additional few special(parrot,ref control) rules controlled by SrcRewrite or TypeRewrite[additional private call range control] properly working.

I hope this commit should be remove for keep consistency.

Solved #57 by adding the IdRewrite=RFId,NetId rule to the network configuration section. Multiple such rules can be specified for one network. Matching source Id is rewritten before writing to the network, incoming private calls to the Network Id are rewritten to the RF Id.

[HegrJan]

First, an accessibility notice. A source code sample - or whatever you've stored there - shouldn't be stored in images. As I'm blind I unfortunately cannot review your suggestion. And it has other consequences as well.

The IdRewrite rule is used for rewriting IDs for given network, not for routing the traffic to a specific network upon the ID, therefore it has independent level. I don't feel persuaded it breaks consistency.

On 5/23/19, d51r3verse notifications@github.com wrote:

I agree with g4klx, seems abusing features. Also you implemented so complicated... You can just change orders every SrcRewrite first, then TGRewrite. That's all. No need to add bunch of codes... and I think you break consistency( Final level rewrites only RFRewrites, and NetRewrites )

Here is sample of mine( What for?: keep super simple base TGRewrites[1-999999:11000001-11999999],[1-999999:12000001-12999999] for every networks, Additional discard rules controlled by SrcRewrite or TypeRewrite)

I hope this commit should be remove for keep consistency.

Solved #57 by adding the IdRewrite=RFId,NetId rule to the network configuration section. Multiple such rules can be specified for one network. Matching source Id is rewritten before writing to the network, incoming private calls to the Network Id are rewritten to the RF Id.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/g4klx/DMRGateway/pull/83#issuecomment-495149155

[d51r3verse]

Please use exist m_dmr*RFRewrites and m_dmr1NetRewrites. I think it is bad idea to call direct rewrite without return value check.

[HegrJan]

• In current implementation RFRewrites are used to route the traffic to the desired network. Only one (first matching) rewrite rule is applied.
• Either RFRewrites or PassAll rules are applied
• SrcRewrite doesn't change the source ID, but the destination ID; no other original rule did change SrcId.
• As IdRewrite rules are applied (if matched) right before writing to the network having no effect on traffic routing, there's no need to check the return value.

Consider the following (my real case) scenario:

[DMR Network 1]
IdRewrite=2306018,2308358
PassAllTG=2

[DMR Network 2]
IdRewrite=2306018,2308358
PassAllPC=2

• Trace the routing for the Network 2.
• And what if I utilized both timeslots?

On 5/23/19, d51r3verse notifications@github.com wrote:

Please use exist m_dmr*RFRewrites and m_dmr1NetRewrites. I think it is bad idea to call direct rewrite without return value check.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/g4klx/DMRGateway/pull/83#issuecomment-495251559

[d51r3verse]

1: You did not consider XLX network 2: Lack of consideration of NET->RF( complicated exist rewrites + your suspicious IdRewrites )

In current implementation RFRewrites are used to route the traffic to the desired network. Only one (first matching) rewrite rule is applied.

Yes, I know why you are not using generic m_dmr*RFRewrites and nested rewrites( call rewrites directly as XLX rewrites does ). However, Why you use generic m_dmr*NetRewrites and why Group calls only(your CRewriteSrcId does not care call type) especially for NET->RF rewirtes? Even in your own functions, there are no consistency. Probably you using MMDVMHost for personal hotspot, therefore don't need incoming group talk source DMRID translation I thought.

This may not met for others needs I think. And someone confusing(local repeater users) ie) IdRewrite=1,2 never effects if hits SrcRewrite first(control for parrot or special control responses some servers) Because NET->RF processing orders in m_dmr*NetRewrites should be...

CRewriteTG(m_dmrXName, (*it).m_toSlot, (*it).m_toTG, (*it).m_fromSlot, (*it).m_fromTG, (*it).m_range);
CRewriteSrc(m_dmrXName, (*it).m_fromSlot, (*it).m_fromId, (*it).m_toSlot, (*it).m_toTG, (*it).m_range);
CRewriteDstId(m_dmrXName, (*it).m_netId, (*it).m_rfId);
CPassAllTG(m_dmrXName, *it);
CPassAllPC(m_dmrXName, *it);

You just considered only for your environments( /w massive master repo file changed). MMDVMHost is not for personal hotspot only, many others using it for public repeater too. I think this commit not suitable for master repository.