通常、Invite要求のContactヘッダーフィールドは無用です。たとえば、UACとUASは異なるLANにあります。連絡先フィールドは次のようになります。SIPでは、Invite要求にContactヘッダーフィールドが存在する必要があります。
INVITE sip:[email protected] SIP/2.0
Contact: Alice<[email protected]>
.....
ダイアログはまだ作成できますが、連絡先フィールドは使用できません。次に、Contactヘッダーフィールドが必須である理由
連絡先フィールドには、今後の要求のために、呼び出し先が呼び出し元に到達できるアドレスが含まれています。たとえば、呼び出し先がBYEまたはre-INVITEを呼び出し元に送信できるようにする必要があります。
はContactヘッダは述べていますどこ Fromヘッダーあなたが誰であるか言いながら、あなたは、（というか、あなたのユーザエージェントがどこにあるか）です。
複数のSIPデバイスがすべて同じレコードのアドレス（Fromヘッダーに入れたURI）に登録されていることがあります。
さらに、REGISTER要求では、Contactヘッダーを使用してSIPのロケーションサービスを維持します。これにより、ユーザーエージェントはレジストラのロケーション情報を更新できます。
（AliceがBobに電話をかけた場合、Contactヘッダーは2xxの応答にする必要があるため、AliceがBobに2xxのACKをルーティングできるようにする必要があります）ContactヘッダーをマージするSIPプロキシについてのDarkDustのコメント：アリスは、ACKを送信したためにコールの設定を考えていますが、ボブはそれを受け取っていません。コンタクトマングリングプロキシの代わりに、B2BUAを使用しています
連絡先ヘッダーでLAN IPを使用することの欠点のために、Phoenix Luoのコメントに対する応答として、連絡先ヘッダーを変更する必要はありません。 RFC 5627は、溶液連絡先ヘッダー/ s内のバリールーティング可能なユーザーエージェントURI （GRUUs）
私が関与しているプロジェクトでは、ロケーションサービスのプロキシがレコードルートヘッダーをInviteリクエストに追加します。したがって、呼び出しを正常に構築できます。しかし、UASからのBye要求は、DarkDustが言ったようにUACによって受け取ることはできません。 –
はい：BYEは呼び出し中の_userエージェント_に送信され、そのユーザーエージェントはFromヘッダーではなくContactヘッダーで識別されます。だから私たちはRFC 5627（セッション開始プロトコル（SIP）のグローバルルーティング可能ユーザエージェントURI（GRUU）の取得と使用）のようなものを発明しなければならなかったのです –
ありがとう。私はこの文書を注意深く読んでいます。 –
ありがとうございます。私はpjprojetでテストをしました。連絡先フィールドが上記の場合、着信者が送信したBYEは発信者に届くことはありません。 –
連絡先がプライベートLANアドレスである可能性があります。あなたの呼び出し先が別のネットワークにある場合、その呼び出し先に到達することはできません。これは、SIPプロキシが使用されていることの1つです。ネットワーク境界にあり、連絡先ヘッダーを管理して、相手が前述のアドレスに到達できるようにします。 – DarkDust
ありがとうございます。あなたの助けを借りて、私は問題を修復しました。 –