cross server redis subscription

[Eric Tamme]

Following up from a question I posted at

https://github.com/sipwise/rtpengine/issues/1534

I am trying to understand what exactly "redis-write" and "redis-read" mean.

If I have server A and server B, each running their own redis instance, for server A I would want my "redis-write" to be server A ip, and "redis-read" to be server B ip?

In this case rtpengine would write everything to redis on host A ... but in the event it crashes or something ... it would still restart and read from itself? or would it read from host B?

grepping through the source I dont see any references to "redis-read" I presume that is just ... "redis=" in the config?

Thanks in advance,

Eric

[Richard Fuchs]

On 01/09/2022 10.17, Eric Tamme wrote:
> Following up from a question I posted at
>
> https://github.com/sipwise/rtpengine/issues/1534
>
> I am trying to understand what exactly "redis-write" and "redis-read"
> mean.
>
> If I have server A and server B, each running their own redis
> instance, for server A I would want my "redis-write" to be server A
> ip, and "redis-read" to be server B ip?

It doesn't really matter where each Redis server is running. You can
have rtpengine A write to Redis A, and then rtpengine B would read from
Redis A. Or you can have rtpengine A write to Redis B and rtpengine B
read from Redis B. I think you could also have rtpengine A write to
Redis A, Redis A replicate to Redis B, and then rtpengine B read from
Redis B. (I think you can even just use a single Redis and use different
DB numbers)

> In this case rtpengine would write everything to redis on host A ...
> but in the event it crashes or something ... it would still restart
> and read from itself? or would it read from host B?

With active/active keyspace notifications: During startup, first calls
are restored from the "read" Redis, from the DB numbers that it would
subscribe to for notifications, and these calls are marked as "foreign."
Second, calls are restored from the "write" Redis DB, and these calls
are marked as "owned."

Where each Redis instance should be running depends on how you've set up
Redis: with or without persistence, with or without replication, etc.
(We use a local "write" DB and a remote "read" DB, without replication.)

> grepping through the source I dont see any references to "redis-read"
> I presume that is just ... "redis=" in the config?

Yes, sorry - there was a separate "redis-read" config option at some
point, but now I remember that it has been removed because it was
redundant. So just "redis" is the "read" DB config, and this is where
notifications would be set up.

Cheers

[Eric Tamme]

Thank you for your response, it helped me to understand a little better, though things still feel a bit fuzzy :)

Sort of a side note question, I see here https://github.com/sipwise/rtpengine/wiki/Redis-keyspace-notifications#rtpengine1

There is a mention of how the interfaces are named and that "pub" prefix is required.  Again looking through the source code I cant find any specific reference to "pub" does the -i parameter identify "self" to rtpengine in terms of OWNED vs. FOREIGN?  In my particular use case, rtpengine is dual homed and bridging rtp across two networks (two interfaces)

[Richard Fuchs]

On 01/09/2022 11.44, [EXT] Eric Tamme wrote:
> Thank you for your response, it helped me to understand a little
> better, though things still feel a bit fuzzy :)
>
> Sort of a side note question, I see here
> https://github.com/sipwise/rtpengine/wiki/Redis-keyspace-notifications#rtpengine1
>
>
> There is a mention of how the interfaces are named and that "pub"
> prefix is required.  Again looking through the source code I cant find
> any specific reference to "pub" does the -i parameter identify "self"
> to rtpengine in terms of OWNED vs. FOREIGN?  In my particular use
> case, rtpengine is dual homed and bridging rtp across two networks
> (two interfaces)

I'm a bit confused about what this wiki page is talking about myself.
There's nothing magic about an interface called "pub" or having a "pub"
prefix. What's important is that local addresses used by one rtpengine
instance must become available and addressable to another instance when
failover happens. This can be achieved through load balancers, possibly
with NAT in place, or things like Pacemaker, etc. Rtpengine itself
doesn't handle this because it can't.

The first interface in the interface config list is the one used by
default, if no other interface is specified. In the example from the
wiki, rtpengine1 would use pub1 by default and rtpengine2 would use pub2
by default. Then when r1 fails and r2 ought to take over, the address
used by pub1 must become available to r2 (if it isn't already), at which
point r2 would start handling r1's calls. It would use the same local
address because pub1 is configured with the same address on r2, just not
as the default interface, so it would remain unused for r2's "own" calls
by default.

If you're bridging RTP between two networks, you need to take care that
interface configurations match between instances and that the signalling
to each rtpengine instance instructs each instance to use the correct
interfaces.

The only thing that distinguishes "owned" from "foreign" calls is how
they were created. If a call is created from direct signalling or from
the "write" DB during startup, then it's "owned," and if it's created
from the "read" DB then it's "foreign" (but may become "owned" at some
point if failover happens).

Cheers