Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,181 4 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

@darwvin-dev đang làm issue này rồi.

Từ ngày 13/10/2026.

  • #2204 của @darwvin-dev — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
redis
Lĩnh vực
databases

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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?

Ngôn ngữ chính
Perl
Star
992
Fork
459
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của sipwise/rtpengine

Tất cả issue của sipwise/rtpengine

Issue tương tự

Thêm issue về Perl

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.