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

クローズ
  • 何か問題がありますか？
#2,230 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
57/100
issue の種類
ドキュメント
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c
領域
backend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Perl
スター
992
フォーク
459
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sipwise/rtpengine のほかの issue

sipwise/rtpengine の issue をすべて見る

似ている issue

Perl の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。