`--timeout` closes a held (sendonly/recvonly) call after 60 s; docs say a call is removed only when all streams go dead

Đã đóng
  • Có gì không ổn?
#2,230 0 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 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
57/100
Loại issue
Tài liệu
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c
Lĩnh vực
backend

Hướng nghiên cứu

The report points to docs/rtpengine.md lines 273–285 and call_timer_iterator() in daemon/call.c lines 219–239; read the timeout logic and commit 750f0a88 to establish the intended behavior. Clarify the --timeout and --silent-timeout documentation to match that behavior. Done when the docs explain how muted streams and sendonly streams affect call lifetime.

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

Mô tả

rtpengine version the issue has been seen with

mr26.3.1.2 (3a3ef61), built from the tag, userspace only. The same logic is on master at f950a9f.

Used distribution and its version

Debian 13 (container)

Linux kernel version used

6.8.0-90-generic (kernel module not used)

CPU architecture issue was seen on

aarch64

Expected behaviour you didn't see

docs/rtpengine.md (L273-L285) says two things:

  • a call is removed when all of its media streams go dead;
  • --silent-timeout applies to muted or inactive streams.

Hold is usually an offer with a=sendonly and an answer with a=recvonly. The answerer's
streams are muted, so by the docs they should be dead only after --silent-timeout. A held
call should therefore stay until then, just like a call held with a=inactive.

Unexpected behaviour you saw

If the holding side sends no RTP or RTCP (no hold music), the call is closed after
--timeout, the same as a fully silent sendrecv call. A held call with a=inactive on both
sides is kept.

In call_timer_iterator():

  • the sendonly side's streams count as receive streams, so recv_checked is set;
  • the recvonly side's silent_good result is then never used
    (daemon/call.c#L219-L239).

The media RECV flag comes from the party's own SDP direction
(daemon/call.c#L3959-L3963).

The message of commit 750f0a88 ("improve timeout handling") describes this as intended:
"only consider the silent-timeout for calls that have no receive streams at all". If so, only
the documentation is out of date.

Steps to reproduce the problem

  1. Start rtpengine:

    rtpengine --foreground --log-stderr --table=-1 --interface=127.0.0.1 --listen-ng=127.0.0.1:2223 --timeout=60 --silent-timeout=3600 --port-min=30000 --port-max=30100

  2. Over NG, create four calls with one PCMU m=audio line each. Nobody sends RTP or RTCP.

    Call-ID Offer Answer
    sendonly-recvonly a=sendonly a=recvonly
    inactive-inactive a=inactive a=inactive
    sendrecv-sendrecv a=sendrecv a=sendrecv
    hold-reoffer a=sendrecv, then a re-offer with the same tags and a=sendonly a=sendrecv, then a re-answer with a=recvonly

  3. Send query for each call at +30, +55, +70 and +100 s.

Additional program output to the terminal or logs illustrating the issue

t=+55s  all four calls: ok
t=+70s  sendonly-recvonly: error Unknown call-id
t=+70s  inactive-inactive: ok
t=+70s  sendrecv-sendrecv: error Unknown call-id
t=+70s  hold-reoffer: error Unknown call-id
t=+100s inactive-inactive: ok (the other three still unknown)

INFO: [hold-reoffer]: [core] Closing call due to timeout
INFO: [sendrecv-sendrecv]: [core] Closing call due to timeout
INFO: [sendonly-recvonly]: [core] Closing call due to timeout

Anything else?

If the behaviour is intended, the --timeout/--silent-timeout text could say so:

  • muted streams only keep a call alive when it has no stream that is expected to send;
  • a sendonly party therefore has to send RTP or RTCP within --timeout.

If it is not intended, the recvonly side's silent_good result could also be considered while
the sendonly side is silent.

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.