Q: SIPキャリアやベンダーがRoutrとの相互運用性を認証し、interopテストの録音を見つけるにはどうすればよいですか？

パートナー相互運用性の記録は `interop/ /` 配下に配置されます（例：WhatsApp Business Calling の場合は `interop/whatsapp/`）。各ディレクトリには、日付付きの `.jsonl` SIP トレース、`manifest.yaml`、`RESULTS.md` に記録された合格/不合格チェックリストの結果が含まれ、認定プロセスは `interop/README.md` に文書化されています。SEET コンプライアンスフィクスチャは `etc/corpus/` に保持されます。相互運用性を検証するには、`npm run compat -- --sip-connect` を実行します。これにより、1つの dispatcher/connect/location チェーンが起動し、まず `etc/corpus/manifest.yaml` がリプレイされ、次に `rctl trace compat --fail-on error` を介してすべての `interop/*/manifest.yaml` がアルファベット順にリプレイされます。各マニフェストの前に `== ` の行が出力されます。すべてのマニフェストは、共有の `etc/corpus/resources` ディレクトリからリプレイリソースを解決します。終了コード 0 はクリーン、4 はドリフトを意味します。1つが失敗した後もすべてのマニフェストが実行され、スクリプトは最初の非ゼロステータスで終了します。error レベルの検出結果は実行を失敗させ、warning は出力のみです。`draft: true` とマークされた記録（2026-10-25 の WhatsApp トレースなど）は、レビュー後にのみ証拠としてカウントされます。

Question 1

Bitnami の PostgreSQL および Redis イメージが存在しなくなったために Routr の Helm インストールが失敗する問題を修正する方法

Accepted Answer

Bitnami はコンテナイメージを `bitnamilegacy` リポジトリへ移動しました（bitnami/charts#35164 を参照）。そのため、Routr Helm チャートが参照するデフォルトの `bitnami/postgresql` および `bitnami/redis` イメージはプルできなくなりました。インストール時にイメージリポジトリを上書きしてください:

```bash
helm repo add routr https://routr.io/charts
helm repo update
helm install sipnet routr/routr-connect --namespace sipnet \
  --set postgresql.image.repository=bitnamilegacy/postgresql \
  --set redis.image.repository=bitnamilegacy/redis
```

これにより、PostgreSQL と Redis の両方の依存関係がレガシー Bitnami レジストリを参照するようになり、チャートを正常にデプロイできます。

Question 2

環境変数の代わりに設定ファイル（one.yaml）を使ってroutr-oneを設定するにはどうすればよいですか？

Accepted Answer

コンテナ内の `/etc/routr/one.yaml` にYAMLファイルをマウントしてください（または `ROUTR_ONE_CONFIG` で別のパスを指定してください）。イメージに同梱されている `/etc/routr/one.example.yaml` のサンプルから始めてください（リポジトリ内では `config/one.example.yaml` にもあります。ドキュメントサイトにこのファイルが掲載されるまでは、これを参照してください）。設定は `spec.*` キーで行います。例えば、外部Postgresの場合は `spec.database.url` と `spec.database.startInternal` です。`${VAR}` 参照はコンテナの環境変数を読み取ります（そのため `${POSTGRES_PASSWORD}` には `-e POSTGRES_PASSWORD` を渡してください）。また、`secret://file/` はコンテナ内のファイルからシークレットを読み取ります。ファイルを保護してください: `sudo chown 5000:5000 one.yaml && chmod 600 one.yaml`、そして決してコミットしないでください。Kubernetesでは、`subPath: one.yaml` を使ってSecretから `/etc/routr/one.yaml` にマウントしてください。`/etc/routr` ディレクトリ全体にSecretをマウントすると、`log4j2.yaml`、`rtprelay.yaml`、`certs/`、およびサンプルが隠れてしまいます。重要な注意点: `ENV_MAP` にマッピングされている環境変数（`mods/one/src/config/env_map.ts`、例: `DATABASE_URL`、`PKCS12_PASSWORD`）を `${...}` 参照で指定してはいけません。イメージはデフォルト値（`PKCS12_PASSWORD=changeme`、内部 `DATABASE_URL`）をENVに焼き込んでいるため、`-e` フラグを外すと `url: ${DATABASE_URL}` は何の警告もなく静かに内部データベースに戻ってしまいます。代わりに `${ROUTR_DB_URL}` や `${ROUTR_KEYSTORE_PASSWORD}` のような新しい名前を使用してください。マッピングされた環境変数は簡単なテストには引き続き使えますが、非推奨の警告がログに出力されます。ファイルベースの設定は、PR #461 を含む routr-one リリースでサポートされています（`gh release list` / `git tag --contains ` で確認してください。ENV_MAP は v2.28.0 以降 main に含まれています）。

Question 3

マウントされた /etc/routr/one.yaml 設定ファイルが、Fonoster routr-one Docker イメージによって無視されるのはなぜですか？

Accepted Answer

影響を受けるroutr-oneイメージでは、コンテナのCMDがPostgres、マイグレーション、keystore、EdgePortを環境変数のみから起動していたため、マウントされた`/etc/routr/one.yaml`は`spec.recording`以外には効果がありませんでした。修正方法: 修正が含まれるイメージ（v2.30.0以降）を使用してください。このイメージは起動時に`print_env`を実行するため、ファイル内のすべてのキーが有効になります。UID 5000で読み取り可能となるようにファイルをマウントしてください: `docker run -d -v $PWD/one.yaml:/etc/routr/one.yaml:ro -e POSTGRES_PASSWORD=… -e KEYSTORE_PASSWORD=… fonoster/routr-one:latest`。ファイルが存在しない場合、動作に変更はなく、すべての環境変数は引き続き機能します。古いイメージでの回避策: ファイルの代わりに、キーと環境変数の対応表にある`-e`環境変数を使ってすべてを設定してください。ロールバック時の注意: 古いタグ（例: 2.27.0）に戻すとファイルが再び読み取れなくなり、ファイルのみの設定は内部データベースとデフォルトの`changeme` keystoreパスワードにフォールバックするため、先に同等の環境変数を復元してください。

Question 4

Routr One が 'pg_ctl: directory is not a database cluster directory' で失敗するのはなぜですか？

Accepted Answer

Postgresデータディレクトリ /var/lib/postgresql/data が初期化されていません。データベースクラスターを作成するには「initdb -D /var/lib/postgresql/data」を実行するか、初回起動時に自動的に初期化される公式のPostgres Dockerイメージ（例：postgres:15）を使用していることを確認してください。Routr Oneの場合、docker-compose.ymlに名前付きボリュームを使用したPostgresサービスを含めてデータを永続化し、ディレクトリのパーミッションを確認してください。

Question 5

SIPキャリアやベンダーがRoutrとの相互運用性を認証し、interopテストの録音を見つけるにはどうすればよいですか？

Accepted Answer

パートナー相互運用性の記録は `interop//` 配下に配置されます（例：WhatsApp Business Calling の場合は `interop/whatsapp/`）。各ディレクトリには、日付付きの `.jsonl` SIP トレース、`manifest.yaml`、`RESULTS.md` に記録された合格/不合格チェックリストの結果が含まれ、認定プロセスは `interop/README.md` に文書化されています。SEET コンプライアンスフィクスチャは `etc/corpus/` に保持されます。相互運用性を検証するには、`npm run compat -- --sip-connect` を実行します。これにより、1つの dispatcher/connect/location チェーンが起動し、まず `etc/corpus/manifest.yaml` がリプレイされ、次に `rctl trace compat --fail-on error` を介してすべての `interop/*/manifest.yaml` がアルファベット順にリプレイされます。各マニフェストの前に `== ` の行が出力されます。すべてのマニフェストは、共有の `etc/corpus/resources` ディレクトリからリプレイリソースを解決します。終了コード 0 はクリーン、4 はドリフトを意味します。1つが失敗した後もすべてのマニフェストが実行され、スクリプトは最初の非ゼロステータスで終了します。error レベルの検出結果は実行を失敗させ、warning は出力のみです。`draft: true` とマークされた記録（2026-10-25 の WhatsApp トレースなど）は、レビュー後にのみ証拠としてカウントされます。

Routr

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト