Session Initiation Protocol (SIP) アプリケーションを開発する際は、製品の特定のランタイム動作を考慮する必要があります。
SIP コンテナーは、要求 URI のスキームを認識しない場合には、メッセージをリジェクトしません。これは、コンテナーがアプリケーションでサポートされている URI スキームを知ることができないためです。 SIP エレメントは、sip または sips 以外のスキームを持つ要求 URI をサポートする場合があります。例えば、pres: スキームは、存在サーバーに対して特定の意味を持ちますが、コンテナーはこれを認識しません。 特定のスキームを受け入れるかリジェクトするかの判断は、アプリケーションによって異なります。 SIP エレメントは、使用可能なメカニズムを使用して、SIP 以外の URI を SIP URI、SIPS URI、または RFC 2806 [9] の tel URI スキームなどのその他のスキームに変換することがあります。
複数コンテナー環境 (SIP プロキシーと SIP コンテナー) では、アプリケーションが最初は外部に送信し、後で受信する要求を送信する場合、最も近くのロード・バランシング・エレメント (複数の SIP プロキシーの場合は IP スプレイヤー、SIP プロキシーが 1 つのみの場合は SIP プロキシー) のホストおよびポートを使用する必要があります。 アプリケーションが最も近くのエレメントの代わりにコンテナーのホスト名を使用した場合、要求は失敗イベントの中で失われる場合があります。
例えば、アプリケーションが自分自身に INVITE 要求を送信し、この要求がプッシュされた経路ヘッダーを通じて外部のアカウンティング・システムを通過する必要があるとします。 アプリケーションは、フェイルオーバーが実行されるように、INVITE 要求の URI を第一のエレメントのホストおよびポートに設定する必要があります。 要求はプッシュされた経路を通じてアカウンティング・システムに送付され、次に処理のために近くのロード・バランシング・エレメントに送り返されます。