SIPカスタマーインタラクション。 パート2

前回の記事では、プロキシサーバーを使用しないSIPクライアントの単純な相互作用について説明しました。 この相互作用は実際には非常にまれですが、SIPの基本を理解するには最適です。



基本的なことを理解したので、プロトコルの実際の作業に進むことを提案します。



この記事では、3つの質問を検討する予定です。

1. トランスポートプロトコルとプロキシ検索の選択。
2. プロキシを介して作業します。
3. プロキシサーバーへの登録。

トランスポートプロトコルの選択とプロキシ検索

SIPプロトコルは複数のトランスポートプロトコル（UDP、TCP、SCTP、TLS）をサポートしているため、使用するプロトコルを何らかの方法で決定する必要があります。 これを行うにはいくつかの方法があります。



最初の方法では、SIP URIでトランスポートを明示的に指定します（TLSを除く）。 次のようになります。







トランスポートが明示的に指定されていない場合、次のアルゴリズムが適用されます。

1. SIP URIにIPアドレスが含まれている場合、SIP URIにはUDPが使用され、SIPS（セキュアSIP）にはTCPが使用されます。
2. IPアドレスが指定されていないが、ポートが指定されている場合、UDPがSIP URIに使用され、TCPがSIPSに使用されます。
3. IPアドレスとポートはないが、対応するNAPTRレコードがDNSに存在する場合、「SIP + D2U」はUDPに対応し、「SIP-D2T」はTCPを示し、「SIP-D2S」はSCTPを示します。 NAPTRには、プロキシサーバーの検索に使用されるSRVレコードへのリンクが含まれています。 NAPTRが存在しない場合、SRVレコードを検索する要求を実行する必要があります。
4. SRV要求の結果は、プロキシサーバーの名前とポートになります。
5. SRVレコードがない場合は、AまたはAAAA要求が実行されます。 この場合、UDPはSIP URIに、TCPはSIPSに使用されます。

理解を深めるために、sipクライアントに連絡する場合の例を考えてみてください：ivan@domain.ru：







そこで、Ivanのプロキシサーバー設定を見つけました。 ここで、SIPダイアログの一部としてプロキシの使用を検討することを提案します。



NAPTRが何であるかを知らない人への注意。 このタイプのDNSレコードは、この記事を書いたときにしか存在しないため、絶望しないでください。 ここで NAPTRについてもう少し。

プロキシを使用した相互作用

なぜSIPプロキシが必要なのですか？ すでに述べたように、記事の最初の部分の例では、クライアントはお互いのIPアドレスを知っていて、直接通信できました。 実際には、クライアントはほとんどの場合、動的にアドレスを受信するため、このIPまたはそのIPを「記憶」する意味はありません。 この状況で最初に頭に浮かぶのは、DNS Aレコードを使用して実際の有効なアドレスを判別することです。 ただし、次の問題があります。IPアドレスは、ユーザーではなく特定のデバイスを識別します。 SIP相互作用の機能は、メッセージ交換がデバイスデバイスレベルではなく、ユーザーごとに行われることです。 この場合、1人のユーザーが複数のSIPクライアントを同時に使用できます。携帯電話、職場のコンピューター、自宅のコンピューター、およびSIPの電話です。 どうする？



SIPプロトコルは次のソリューションを提供します：SIPプロキシを作成し、各ユーザーがこのプロキシにデバイスを登録します（より正確には、ユーザーは登録サーバーに登録し、プロキシは登録データベースにアクセスしますが、簡単にするために、これは同じサーバーであると仮定します）。 これがどのように行われるか、以下に示します。 今のところ、Proxyはユーザーのクライアントを見つける方法を正確に知っていることを覚えておいてください。



PeterがIvanに電話すると、次の一連のアクションが実行されます。

1. PeterのSIPクライアントがIvanのSIPプロキシのアドレスとプロトコルを決定します（これを行う方法-上記を参照）
2. クライアントがプロキシにINVITE要求を送信します
3. プロキシサーバーは、Ivanが登録したデバイスを確認し、これらすべてのデバイスにリクエストを送信します
4. Ivanはデバイスの1つでコールに応答し、200 OKをプロキシに送信します
5. プロキシはPeterに200 OKをリダイレクトします
6. Peterは、200応答ボックスの[連絡先]フィールドから特定のデバイスでIvanのSIPアドレスを受信し、Prxoyをバイパスして直接応答を送信します
7. その後の通信もすべて直接です。

図では、次のようになります。







記事の最初の部分を学習した人にとっては、すべてがかなり馴染みのあるものに見えます。 中間プロキシサーバーのみが追加されました。 したがって、メッセージングは​​わずかに変更されました。



詳細な検査に入る前に、ちょっとした発言をします。 SIP内では、2種類のURIが共有されます。 最初の1つはユーザーURIであり、アドレスのアドレス（AOR）とも呼ばれます。 このアドレスに送信される要求には、プロキシデータベースの検索と1つまたは複数のデバイスへの要求の送信が含まれます。 2番目はデバイスURI（または、むしろデバイス上のユーザー）です。 デバイスURIは通常、連絡先と呼ばれ、それぞれSIPメッセージのContactフィールドに含まれています。 AORは、FromおよびToフィールドに含まれています。

会話の始まり

したがって、ピーターはIvanのINVITEをプロキシサーバーに送信します。





プロキシサーバーは、リクエストをすべてのIvanのSIPクライアントにリダイレクトします。 簡単にするために、Ivanが1つのデバイスのみを使用すると仮定します。 SIPクライアントがリクエストがプロキシを介してリダイレクトされたことを理解するために、サーバーはviaヘッダーフィールドを追加します。







IvanのSIPクライアントは180 Ringing応答を送信します（Ivanは呼び出しを聞きます）。 同時に、彼はToフィールドにタグを追加し、Contactフィールドに自分の連絡先を示します。 さらに、最初のviaフィールドに受信パラメーターが追加されました。このパラメーターは、Ivanのクライアントがリクエストを受信したアドレス（つまり、Ivanが見るプロキシサーバーのアドレス）を示します。 問題を解決するためにこれを知ることは有用です：







したがって、プロキシはリクエストをピーターのクライアントにリダイレクトします。 同時に、彼はビアを削除します：







180の呼び出し音を送信した後、Ivanが電話を拾うとすぐに、IvanのクライアントはPrxoyに200 OK応答を送信します。







Proxyはこの回答をPeterに渡しますが、次の方法で削除します。







今から楽しい部分です。 Peterのクライアントは、プロキシをバイパスして、ASKメッセージをIvanのクライアントに直接送信します。 さらに、Ivanが同時に複数のSIPクライアントを使用した場合、答えはまさに必要なものになりました。 何がこれを可能にしますか？



Ivanが電話をピックアップしたクライアントから送信された200 OK。 さらに、200 OK応答のContactフィールドには、特定のデバイスのユーザーIvanに対応するURIが含まれています。 したがって、PeterのクライアントはこのデバイスにACKを送信します。その後、Proxyの参加は不要になります。







メディアトラフィックを含む他のすべてのメッセージは、プロキシをバイパスします。

会話の終わり

会話の最後に、IvanのクライアントはBYEをPeterのクライアントに直接送信します。







応答としてピーターは確認を送信します：





ここでは、記事の最初の部分のようにすべてがあります。



そこで、SIPクライアントとプロキシサーバーの参加との相互作用を調べました。 質問が1つだけ残っていました。プロキシはどのようにしてIvanのクライアントのアドレスを見つけましたか？ 登録手順を使用します。 これがどのように起こるか、以下で説明します。

SIP登録

登録は次のとおりです。







各メッセージを詳しく見てみましょう。 Ivanはサーバーに登録要求を送信します（簡単にするために、登録サーバーの役割はproxy.domain.ruにインストールされていると考えています）。 このリクエストで最も重要なのは、連絡先フィールドです。 これは、特定のデバイス上のIvanのアドレスです。







応答として、サーバーは401 Unauthorized、つまり承認要求を送信します。 答えの中で最も重要なフィールドはWWW-Authenticateです。 レルムがドメインであると推測するのは難しくありません。アルゴリズムは、使用するハッシュアルゴリズムを示します。 興味深いのは、ナンスフィールドです。







Nonceは、「一度使用した番号」の略です。 Nonceは1回限りのランダムシーケンスであり、Ivanのクライアントはパスワード文字列と組み合わせて、受信した文字列からMD5ハッシュを生成し、結果をWWW-Authenticateフィールドに新しいリクエストに入れます（実際、すべてが多少複雑ですが、簡単にするために、それだけです）。 これを行うには、応答パラメーターを使用します。



なぜノンスが必要なのですか？ クライアントがパスワードからMD5を生成し、ノンスを使用しなかった場合、ハッシュは毎回同じになります。 攻撃者はそのようなハッシュを傍受し、それを認証に使用する可能性があります。 これは、パスワードをクリアテキストで送信するのと同じくらい安全ではありません。



nonceを使用すると、MD5は毎回新しい行から取得され、異なることが判明します。 そのため、攻撃者はハッシュを傍受したとしても、ほとんどの場合、認証に使用できません。



ちなみに、新しい登録要求にはもう1つのCSeqがあることに注意してください。







サーバーはまた、ナンスをIvanのパスワードと組み合わせて、MD5ハッシュを受け取ります。 その後、彼は自分のハッシュとイヴァンから受け取ったハッシュを比較します。 一致する場合、サーバーは200 OKを送信します。 expiresパラメーターが[連絡先]フィールドに追加されていることに注意してください。 この場合、登録はサーバーデータベースに3600秒または1時間保存されます。







Ivanが登録を更新する場合は、この時間内に別のREGISTERを送信する必要があります。



Ivanが一度にSIPサポートのある複数のデバイスを使用するとどうなりますか？ すべてが非常に簡単です-それぞれから登録要求を送信する必要があります。



対応するエントリがこの登録サーバーのデータベースに表示されると、プロキシサーバーはリクエストをIvanのSIPクライアントにリダイレクトできるようになります。

興味がある人のためのボーナス

サーバーは、登録要求への応答として、Toタグを含む応答を送信します。







ダイアログを設定するときに、このタグが同じメッセージを再度受信するのを防ぐのに役立つことは明らかです。 これにはルールがあります。メッセージにToタグが含まれておらず、UASが同じCSeq、Fromタグ、Call-IDのメッセージをすでに受信している場合、メッセージは破棄されます。 登録サーバーとの対話を確立しない場合、なぜToタグが必要なのですか。 私が見つけることができる最良の答えは、RFC 3261で、Toタグなしで要求に来る200 OK応答にはToタグを含めるべきだということです。 つまり、何もする必要はありませんが、受け入れられます。



この記事を読んだ後、SIPプロトコルの機能がより理解しやすくなることを願っています。 あなたのコメントを歓迎します。