Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Calls using a third logical interface are silently never written to Redis (breaks keyspace-notification HA)

Open
  • Is something wrong?
#2,181 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

@darwvin-dev is already working on this.

Since Oct 13, 2026.

  • #2204 by @darwvin-dev — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
redis
Domain
databases

Research direction

Reproduce first: send synthetic offer commands to the ng port that differ only in direction (['internal','external'] vs ['int','trunk']) and compare the call-ids present in the node's Redis DB, per the table in the report. Then trace how the configured interface list and the external=pub;internal=int aliases are mapped onto the names used when serialising the bencode record, and find the gate that decides whether the call is written to Redis at all. Done when a call touching trunk (or the renamed pubtrunk) is persisted, adoptable on failover, and restored after restart.

Written by the indexing model from the issue text.

Description

Summary

With Redis keyspace-notification HA configured, a call is written to Redis only when both of its logical interfaces are the ones aliased to external/internal. A call that uses any additional logical interface is silently omitted from Redis — no error, and nothing logged even at log-level = 7.

The consequence is that such calls have no standby copy on peers, cannot be adopted on failover, and are not restored by the owning instance after a restart — they are lost permanently.

Version

mr13.5.1.6 (ngcp-rtpengine-daemon 13.5.1.6+0~mr13.5.1.6), Debian 13.

Configuration
table = 0
interface = pub/10.0.0.10!192.0.2.50;int/10.0.0.10;trunk/10.0.0.10!192.0.2.53;external=pub;internal=int
redis = <pw>@10.0.0.20:6381/4
subscribe-keyspace = 5;6
active-switchover = true
no-redis-required = false
redis-format = bencode

The third interface trunk exists to advertise a second public address on the external side (carrier-facing media on a different public IP from subscriber-facing media).

Reproduction

Send synthetic offer commands to the ng port that differ only in the direction flag, then compare the call-ids present in the node's Redis DB:

direction present in Redis
["internal", "external"] yes
["int", "pub"] (raw names, same interfaces) yes
["int", "trunk"] no
["internal", "trunk"] no

All four calls are created successfully and appear in list sessions all with redis: 4. Only the first two ever appear in the database.

What I ruled out
  • Not no-redis-update — not passed by the caller, and not present in any configuration here.
  • Not the advertised address — pub also carries one (!192.0.2.50) and persists fine.
  • Not raw-name vs alias resolution — ["int", "pub"] using the underlying names persists.
  • Not the pub name prefix. The wiki for Redis keyspace notifications states the pub prefix is essential, so I renamed trunk to pubtrunk and retested: still not persisted.
  • Not interface ordering — moving pubtrunk to the second position in the interface list: still not persisted.

The only property that correlates with persistence across all six variants is whether the interface is one of the two aliased as external/internal.

Expected vs actual

Expected: any call the instance owns is written to Redis, regardless of which configured logical interface it uses.

Actual: calls touching a third logical interface are omitted, silently. If this is intended, it would be very helpful to have it stated in the Redis keyspace-notifications documentation and, ideally, logged or rejected at configuration time — as it stands, the HA appears fully configured and functional right up until a failover is attempted.

Question

Is supporting more than two logical interfaces under Redis HA in scope? If not, is running a second instance per host (separate table, listen-ng, port range and Redis DB) the recommended way to serve two externally-advertised media addresses with HA?

Dominant language
Perl
Stars
992
Forks
459
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sipwise/rtpengine

All issues in sipwise/rtpengine

Similar issues

More Perl issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.