Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#2,181 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

@darwvin-dev ci sta già lavorando.

Dal 13/10/2026.

  • #2204 di @darwvin-dev — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
redis
Ambito
databases

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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?

Lingua principale
Perl
Stelle
992
Fork
459
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sipwise/rtpengine

Tutte le issue di sipwise/rtpengine

Issue simili

Altre issue su Perl

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.