Session-initiation-protocol-mobility

提供:Dev Guides
移動先:案内検索

SIP-モビリティ

  • パーソナルモビリティ*は、多数のデバイスで一定の識別子を保持する機能です。 SIPはREGISTERメソッドを使用して基本的なパーソナルモビリティをサポートします。これにより、モバイルデバイスはIPアドレスとインターネットへの接続ポイントを変更し、着信コールを受信できます。

また、SIPは*サービスモビリティ* –モバイル時に同じサービスを維持するユーザーの能力もサポートできます。

ハンドオーバー中のSIPモビリティ(プレコール)

デバイスは、単純なsip登録により、連絡先URIをレコードのアドレスにバインドします。 デバイスのIPアドレスに応じて、登録により、この情報はSIPネットワークで自動的に更新されます。

ハンドオーバー中に、ユーザーエージェントは異なるオペレーター間をルーティングし、別のサービスプロバイダーのAORとして連絡先に再度登録する必要があります。

たとえば、次のコールフローの例を見てみましょう。 新しいサービスプロバイダーで新しいSIP URIを一時的に受信したUA。 次に、UAは二重登録を実行します-

  • 最初の登録は、デバイスの連絡先URIを新しいサービスプロバイダーのAOR URIにバインドする新しいサービスオペレーターによるものです。
  • 2番目のREGISTERリクエストは元のサービスプロバイダーにルーティングされ、新しいサービスプロバイダーのAORが連絡先URIとして提供されます。

コールフローの後半で示すように、元のサービスプロバイダーのネットワークにリクエストが届くと、INVITEは新しいサービスプロバイダーにリダイレクトされ、新しいサービスプロバイダーはコールをユーザーにルーティングします。

SIP Mobility

最初の登録の場合、デバイスURIを含むメッセージは次のようになります-

REGISTER sip:visited.registrar1.com SIP/2.0
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca
Max-Forwards: 70
To: Tom <sip:UA1@registrar1.in>
From: Tom <sip:UA1@registrar1.in>;tag = 72d65a24
Call-ID: 4e719d1c1fc9000803630373300@172.22.1.102
CSeq: 1 REGISTER
Contact: <sip:Tom@172.22.1.102:5060>
Expires: 600000
Content-Length: 0

ローミングURIを持つ2番目の登録メッセージは次のようになります-

REGISTER sip:home.registrar2.in SIP/2.0
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u
Max-Forwards: 70
To: Tom <sip:UA1@registrar2.in>
From: Tom <sip:UA1@registrar2.in>;tag = 45375
Call-ID:87nr43i@172.22.1.102
CSeq: 6421 REGISTER
Contact: <sip:UA1@registrar2.in>
Content-Length: 0

上記の図に示されている最初のINVITEは、sip:registrar2.inに送信されます。 2番目のINVITEはsip:sip:Tom@registrar2.inに送信され、* sip:Tom@172.22.1.102*に転送されます。 トムに到達し、セッションを確立できます。 定期的に両方の登録を更新する必要があります。

通話中のモビリティ(再招待)

ユーザーエージェントは、あるネットワークから別のネットワークにスワップするときに、セッション中にIPアドレスを変更する場合があります。 ダイアログのre-INVITEを使用して連絡先URIを更新し、SDPのメディア情報を変更できるため、基本的なSIPはこのシナリオをサポートします。

下の図に記載されているコールフローを見てください。

  • ここで、トムは新しいネットワークを検出し、
  • DHCPを使用して新しいIPアドレスを取得し、
  • re-INVITEを実行して、新しいIPアドレスへのシグナリングとメディアフローを許可します。

UAが両方のネットワークからメディアを受信できる場合、中断は無視できます。 そうでない場合、いくつかのメディアパケットが失われ、通話がわずかに中断されることがあります。

通話中のモビリティ

再招待は次のように表示されます-

INVITE sip:Jerry@TTP.com SIP/2.0
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a
Max-Forwards: 70

To: <sip:Harry@TTP.com>

From: sip:Tom@PPT.com;tag = 70133df4
Call-ID: 76d4861c19c
CSeq: 1 INVITE
Accept: application/sdp
Accept-Language: en

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE
Contact: <sip:172.22.1.102:5060>;
Content-Type: application/sdp
Content-Length: 168

v = 0
o = PPT 40467 40468 IN IP4 192.168.2.1
s = -
c = IN IP4 192.168.2.1
b = AS:49
t = 0 0
b = RR:0
b = RS:0
a = rtpmap:97 AMR/8000/1
m = audio 6000 RTP/AVP 96
a = fmtp:102 0-15
a = ptime:20
a = maxptime:240

re-INVITEでは、ViaおよびContactヘッダーフィールドにBowditchの新しいIPアドレスとSDPメディア情報が含まれています。

通話中のモビリティ(ヘッダーの交換あり)

ミッドコールモビリティでは、実際のルートセット(SIPメッセージが通過する必要があるSIPプロキシのセット)を変更する必要があります。 ミッドコールモビリティではre-INVITEを使用できません

たとえば、NATトラバーサルにプロキシが必要な場合、連絡先URIを変更する必要があります—新しいダイアログを作成する必要があります。 したがって、既存のセッションを識別するReplacesヘッダーを持つ新しいINVITEを送信する必要があります。

-AとBの両方が通話中で、Aが置換ヘッダー(既存のダイアログと一致する必要がある)を使用して別のINVITE(Cから発言)を取得すると、AはINVITEを受け入れてBとのセッションを終了し、転送する必要があります新しく形成されたダイアログへのすべてのリソース。

次の図にコールフローを示します。 これは、Replacesを含むINVITEが受け入れられると、既存のダイアログを終了するためにBYEが自動的に生成されることを除いて、re-INVITEを使用する以前のコールフローに似ています。

通話中のモビリティ

以下に、このシナリオで注意すべき点を示します-

  • トムとジェリーの間の既存のダイアログには、訪問済みの古いプロキシサーバーが含まれています。
  • 新しいワイヤレスネットワークを使用する新しいダイアログには、新しい訪問済みプロキシサーバーを含める必要があります。
  • その結果、TomによってReplacesを含むINVITEが送信され、新しい訪問済みプロキシサーバーを含むが古い訪問済みプロキシサーバーを含まない新しいダイアログが作成されます。
  • JerryがINVITEを受け入れると、BYEが自動的に送信され、セッションに関与しなくなった古い訪問済みプロキシサーバーを経由する古いダイアログが終了します。
  • 結果のメディアセッションは、INVITEのSDPからのトムの新しいIPアドレスを使用して確立されます。

サービスモビリティ

SIPのサービスは、プロキシまたはUAで提供できます。 ユーザーのデバイスが同じサービスで同一に構成されていない限り、パーソナルモビリティとともにサービスモビリティを提供することは困難な場合があります。

SIPは、インターネットを介したサービスモビリティを簡単にサポートできます。 インターネットに接続されている場合、インドで一連のプロキシを使用するように構成されたUAは、ヨーロッパでローミングするときにそれらのプロキシを引き続き使用できます。 メディアは常に2つのUA間を直接流れ、SIPプロキシサーバーを通過しないため、メディアセッションの品質には影響しません。

エンドポイント常駐サービスは、エンドポイントがインターネットに接続されている場合にのみ利用できます。 エンドポイントでインターネット接続が一時的に失われた場合、エンドポイントに実装された着信転送サービスなどの着信サービスは失敗します。 したがって、一部のサービスは、SIPプロキシサーバーを使用してネットワークに実装されます。