0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

SIP 513 Message Too Large が発生する原因と解決策 〜音声AIとAsteriskの接続トラブルシューティング〜

0
Last updated at Posted at 2026-07-13

1. はじめに

音声AIプラットフォーム(Retell AI や Vapi など)を中継サーバーである Asterisk にSIP接続しようとした際、呼び出し(INVITE)が通らず、ログに SIP/2.0 513 Message Too Large というエラーが記録されて即時切断される現象に遭遇することがあります。

このエラーは、通常のWeb開発ではあまり見かけないIP電話(VoIP)インフラ特有の障害です。

本記事では、このエラーが発生する根本的な原因と、Asteriskの設定を変更して一発で解決するための具体的な方法について解説します。


2. なぜ 513 Message Too Large が発生するのか?

根本的な原因:パケットサイズがUDPの限界を超えたため

SIP接続を開始する際、送信元は INVITE というシグナルパケットを送ります。このパケットの中には、接続情報や対応可能な音声形式(コーデック)などを記載した SDP (Session Description Protocol) や、カスタムの認証ヘッダーが含まれています。

特に、Retell AIなどの海外音声AIプラットフォームは、多数のコーデック候補(G.711, G.722, Opus等)や、NAT越えのためのICE情報、カスタムヘッダーなどをINVITEパケットに大量に詰め込みます。

その結果、パケットサイズが一般的なネットワークの MTUサイズ(通常1500バイト、UDPでの安全値は約1300バイト以下) を大幅に上回ってしまいます。

【Retell AI】
  (巨大なINVITEパケットを送信:約1700バイト)
       ↓   [UDP (Port 5060)]
  [ネットワーク経路]
  (MTUの上限1500バイトを超えるため、パケットが断片化・欠損する)
       ↓
【Asterisk (中継サーバー)】
  (パケットが大きすぎて受信・再構築できない ➔ 513 Message Too Large を返して拒否)

UDPプロトコルは信頼性の保証がない(パケットが壊れても再送されない)ため、サイズが大きすぎてパケットが分割(フラグメンテーション)されると、欠損して通信が成立しなくなります。これに対応するため、SIPの仕様上、サイズが大きいパケットは受信側で拒否してエラーを返すよう定義されています。


3. 解決策:トランスポートを UDP から TCP へ変更する

最も確実で効果的な対策は、Asteriskと音声AIプラットフォーム(Retell AI)間の接続に「TCP」を使用することです。

TCPはパケットの再構築やエラー制御をトランスポート層で自動で行うため、パケットがどんなに肥大化してもフラグメンテーションによる影響を受けず、安全に巨大なINVITEパケットをやり取りできます。

pjsip.conf での具体的な解決コード例

以下のように、Retell AI用の接続設定に transport-tcp を作成して指定し、アウトバウンドプロキシのパラメータに ;transport=tcp を追加します。

; ===========================================================================
; /etc/asterisk/pjsip.conf
; ===========================================================================

; 1. TCP用のトランスポート定義
[transport-tcp]
type=transport
protocol=tcp
bind=0.0.0.0:5060
external_signaling_address=YOUR_PUBLIC_IP
external_media_address=YOUR_PUBLIC_IP
local_net=172.31.0.0/16

; 2. エンドポイントの定義 (TCPトランスポートを紐づける)
[retell]
type=endpoint
transport=transport-tcp ; ← ここでTCPを指定
context=from-retell
disallow=all
allow=ulaw ; 音声コーデックをulawだけに絞ることでパケットサイズを削減
aors=retell-aor
direct_media=no
rtp_symmetric=yes
force_rport=yes
from_domain=sip.retellai.com
; アウトバウンドプロキシでTCPによる通信を強制する
outbound_proxy=sip:sip.retellai.com\;lr\;transport=tcp

ダイアプランでの呼び出し側の対応 (extensions.conf)

ダイアプランから発信する際も、TCPトランスポートを介したSIP URIを指定します。

[from-brastel]
exten => _X.,1,NoOp(Inbound from Carrier)
 same => n,Answer()
 ; TCPトランスポートを明示してRetell AIへダイヤル
 same => n,Dial(PJSIP/retell/sip:+8150XXXXXXXX@sip.retellai.com\;transport=tcp,120)
 same => n,Hangup()

4. サブの対策:不要なコーデックの無効化

TCPへの変更と同時に、接続先エンドポイントで許可する音声コーデックを ulaw(G.711u)のみ など必要最小限に絞り込むことも効果的です。

INVITEパケット内の「対応可能コーデック一覧」の記述が減るため、パケットの絶対的なサイズ自体を縮小させることができます。

disallow=all
allow=ulaw

5. まとめ

SIP 513 Message Too Large エラーが発生した場合は、ネットワーク障害などを疑う前に、**「トランスポートレイヤーをUDPからTCPに切り替える」および「不要なコーデック設定を削除してパケットをダイエットさせる」**という2つのアプローチで即座に解決できます。

特に海外の最新音声AIサービスはリッチなシグナリングを行う傾向があるため、TCP/TLSでの中継設計を基本としてインフラを構築するのが推奨されます。


6. 技術的なサポート・構築代行について

「音声AIとの接続時に513エラーや切断が発生して動かない」
「NAT環境下でのAsteriskのTCPトランスポート設定で困っている」

といった企業・開発者様向けに、接続・構築の専門代行サービスを提供しています。お持ちの回線が接続可能かの「無料診断」も実施しておりますので、詳細やご相談は下記ページからお気軽にお問い合わせください。

👉 [SIPBridge 日本番号対応AI電話構築代行] (https://www.sipbridge.dev/agency)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?