SIP入門
Vonage SIP Interconnect は、WebRTC エンドポイントと既存のテレフォニーシステムとの相互運用性を可能にし、ユーザーがウェブサイトやモバイルアプリケーションを閲覧しながら、インコンテクストで SIP ベースの通話ができるようにします。
REST APIを使用して、SIPプラットフォームをセッションに接続できる。これにより、SIPコールの音声(およびオプションでビデオ)をセッションのストリームとして追加することができる。セッション内の他のストリームの音声はミックスされ、SIPエンドポイントに送信される。SIP通話にビデオを含めると、他の参加者のストリーム(最大9つ)のビデオがグリッドレイアウトに配置され、1つのビデオストリームとしてSIPエンドポイントに送信されます。
SIPインターコネクト機能は、ルーティングされたセッションでのみサポートされます。 メディア・ルーター).
対象ユースケース
コンタクトセンターの使用例
企業顧客は、コミュニケーションのオムニチャネル戦略の一環として、エンドユーザーが利用できるWebRTCに注目している:
よりユビキタスでコンテクスチュアルな体験を提供するために、電話だけでなく、ブラウザやモバイルアプリケーションを使用してコンタクトセンターと接続する。
音声だけでなく、ビデオやコラボレーションを活用することで、効率性を向上させ、顧客満足度と顧客維持率を高める。
PSTNフォールバック
通常のSDKクライアントでは接続できない場合があります:
- 参加者の1人がWebRTCをサポートしていないブラウザを使用している場合、または
- ファイアウォールの制限が厳しすぎる場合
IP/Vonage経由の接続が上記の理由で失敗した場合、顧客はフォールバック・メカニズムが必要になります。SIPインターコネクトにより、お客様はセッション内で通常の電話をかけることができます。お客様はこの目的のためにSIP-PSTNゲートウェイをセットアップする必要があります。
SIPコールの開始
SIPコールを開始するには、REST APIを使用する。以下のURLにHTTPS POSTリクエストを行う:
/v2/project/:app-id/dial
交換 :app-id あなたの APP ID.
を設定する。 Content-Type ヘッダを application/json.また、ベアラ認証ヘッダーを設定する: Authorization: Bearer <token> どこ <token> は JWT を使用して生成されたトークンです。 証明書.
リクエストのボディに以下の形式のJSONデータを設定する:
{
"sessionId": "session ID",
"token": "A valid token",
"sip": {
"uri": "sip:user@sip.partner.com;transport=tls",
"from": "from@example.com",
"headers": {
"headerKey": "headerValue"
},
"auth": {
"username": "username",
"password": "password"
},
"secure": true|false,
"video": true|false,
"observeForceMute": true|false
}
}
JSONオブジェクトには以下のプロパティが含まれる:
sessionId(必須) - 参加するSIPコールのセッションID。token(必須) - 呼び出される参加者に使用されるトークン。参加者がSIPエンドポイントであることを識別するため、または電話番号などのその他の識別データのために、トークンデータを追加できます(クライアントライブラリには、セッションに接続されたクライアントの接続データを検査するためのプロパティが含まれています)。(クライアントライブラリには、セッションに接続しているクライアン トの接続データを検査するためのプロパティが含まれている)。詳細は トークン作成 を案内する。シップ
uri(必須):Vonage からお客様の SIP プラットフォームに発信される SIP コールの宛先として使用される SIP URI。
もしSIP uri を含む。 transport=tls ヘッダがない場合、Vonage と SIP エンドポイント間のネゴシエーションは安全に行われます。これはネゴシエーション自体にのみ適用され、音声の伝送には適用されないことに注意してください。音声(およびビデオも含まれる場合)のメディア伝送も暗号化したい場合は secure プロパティ true.
これは安全なコール・ネゴシエーションの例である:
これは、安全でないコール・ネゴシエーションの例である:
を設定することもできます。 transport ヘッダを transport=tcp または transport=udp.
デフォルトのトランスポートは udp.
- シップ
from(オプション):(オプション): 発信者として最終的なSIP番号に送られる番号または文字列。 (オプション): 発信者として最終的なSIP番号に送られる番号または文字列。の形式の文字列でなければならない。from@example.comここでfromは文字列 または Numbers である。
もし from には数字がセットされる(例えば、 "14155550101@example.com")、その番号は
PSTN電話では着信番号として表示されます。もし from が未定義または文字列
(に設定される(例えば "joe@example.com")、PSTN電話では+000000が着信番号として表示されます。
もし from が未定義であるか、あるいは文字列(たとえば "joe@example.com"である場合
未認識または非認証番号である場合、ほとんどの場合、その番号は次のように変換される。 "Unknown"
リクエストがSIPプロバイダーによってPSTNターミネーションのためにキャリア に転送(forward)される前に。
プロバイダによって異なる、 "Unknown" は、PSTN電話では着信番号として表示されます。
場合によっては、プロバイダーは、番号詐称のような問題を避けるため、セキュリティ上の理由から、そのような着信を拒否することがある。
番号スプーフィングなどの問題を避けるためである。プロバイダーによって着信拒否されない場合、
+000000はPSTN電話の着信番号として表示されます。
番号がE.164でない場合、またはE.164でない場合、その番号は未認識とみなされます。 Vonageバーチャル番号 に接続する場合 に接続する場合は Vonage Voice API, 例えば
シップ
headers(オプション) - このオブジェクトは、SIPヘッダーに追加されるカスタムヘッダーを定義する。INVITEリクエストが OpenTok から SIP プラットフォームに送信されます。シップ
auth(オプション) - このオブジェクトにはusernameそしてpasswordで使用される SIPINVITEHTTPダイジェスト認証がSIPプラットフォームで要求される場合、HTTPダイジェ スト認証のリクエストを作成する。secure(オプション) - メディアを送信しなければならないかどうかを示すブール値のフラグ。 暗号化された (true)または(falseデフォルト)。
呼び出しに成功すると、HTTP 200 レスポンスが返され、接続 ID とストリーム ID が JSON レスポンス・データに含まれる:
{
"id": "b0a5a8c7-dc38-459f-a48d-a7f2008da853",
"connectionId": "e9f8c166-6c67-440d-994a-04fb6dfed007",
"streamId": "482bce73-f882-40fd-8ca5-cb74ff416036",
}
video(オプション) - SIP呼がビデオを含むかどうかを示すブール値のフラグ(true)または(falseデフォルト)。ビデオが含まれている場合、SIPクライアントのビデオはセッションに送信されるVonageストリームに含まれます。SIPビデオは480p、800kbpsに制限される。SIPクライアントは、セッションで公開されたストリームの動的合成ビデオストリームを受信する。observeForceMute(オプション) - SIPエンドポイントが以下を遵守するかどうかを示すブーリアン・フラグ。force mute moderation(true)または(falseデフォルト)。またobserveForceMuteに設定する。true発呼側は、「*6」を押して、公開されている音声のミュートを解除したりミュート したりできる。6」のミュートトグルが機能するためには、SIP発呼側はRFC2833 DTMF (RFC2833/RFC4733 digits)をネゴシエートしなければならない[MUST]。ミュートトグルは、SIP INFOまたは帯域内DTMFではサポートされない。発呼側がミュートおよびミュート解除したとき、またはSIPクライアントが強制 ミュート操作でミュートされたときに、発呼側にメッセージ(英語)が再生される。streams(オプション) - SIP呼に含めるストリームのストリームIDの配列。 の配列。このプロパティを設定しない場合、セッションのすべてのストリームが呼に 含まれる。 呼に含まれる。
呼び出しに成功すると、HTTP 200 レスポンスが返され、接続 ID とストリーム ID が JSON レスポンス・データに含まれる。 が含まれる:
{
"id": "b0a5a8c7-dc38-459f-a48d-a7f2008da853",
"connectionId": "e9f8c166-6c67-440d-994a-04fb6dfed007",
"streamId": "482bce73-f882-40fd-8ca5-cb74ff416036",
}
JSONオブジェクトには以下のプロパティが含まれる:
id- SIPコールの一意のID。connectionId- セッション内のSIPコールのコネクションのコネクションID。このコネクションIDを使用して、REST APIを使用してSIPコールを終了できる。参照 次節.
streamId - セッション内のSIPコールのストリームのストリームID。
SIPゲートウェイは標準的なSIPを送信する。 INVITE を、RESTコールで提供するアドレスに追加する。SIPエンドポイントが接続すると、セッションに新しいコネクションとして追加され、そのオーディオ(およびビデオ(含まれている場合))がセッションの新しいストリームに追加される。新しいコネクションは、SIPエンドポイントが呼を受 信または受け入れるのを待たずに、ただちにセッションに追加される。セッションに接続しているクライアントでは Client SDK は、新しい接続とストリームのイベントをディスパッチします (他の接続とストリームの場合と同じです)。クライアントは、セッション内の他のストリームをサブスクライブするのと同じように、 ストリームをサブスクライブすることができる。
SIPコールの終了
SIPサーバーがBYEメッセージ(呼を終了する)を送信すると、呼は終了する。以下のREST APIメソッドを使用して、通話を終了することもできる。 クライアントを切断する をセッションから削除する。このメソッドを呼び出すときは、SIPコールのコネクションIDを使用する。(RESTメソッドの SIPの開始 の呼び出しは、応答データの一部としてコネクションIDを返す)。
SIP呼が終了すると、SIP呼の接続とストリームも終了する。セッションに接続している各クライアントでは クライアントサイドSDK は、接続とストリームの終了を示すイベントをディスパッチします (他のクライアントがセッションを切断したときと同じです)。
Vonage SIP ゲートウェイは、5 分間の非アクティブ(メディアを受信しない 5 分間)の後、自動的に通話を終了します。また、セキュリティ対策として、Vonage SIPゲートウェイは6時間以上続くSIPコールを閉じます。
DTMF信号の送信
REST APIを使用して、DTMF(Dual-tone multi-frequency)信号をSIPエンドポイントに送信できます。以下を参照してください。 SIPクライアントへのDTMF桁の送信.
テレフォニーイベントはSDP上でネゴシエートされ、RFC4733/RFC2833桁としてリモー トエンドポイントに送信される。
通話進行状況のモニタリング
アプリサーバーでSIPコールのリアルタイムイベントコールバックを受信するために登録します。
開発者は Vonage REST API を使って SIP プラットフォームをセッションに接続することができます。これにより、SIPコールの音声(含まれている場合はビデオ)をセッションのストリームとして追加することができます。
SIPコールモニタリングにより、開発者はアプリサーバー内からSIPコールの進行状況を監視することができます。コールバックに登録することで、コールバックURLは、SIPコールの進行状況に関する情報を含むHTTP POSTリクエストを受け取ります。
コールバックの登録
SIPコール・イベント情報は、サーバー内のHTTPエンドポイントに登録できます。登録されたアクティビティが発生するたびに、HTTPリクエストがVonageインフラストラクチャからエンドポイントに発行されます。
コールバックURLを登録する:
あなたのところへ Vonage Video API アカウント ページを参照されたい。
コールバックを登録するプロジェクトを選択します。
SIP MonitoringセクションでコールバックURLを設定する。
SIPコールアクティビティの監視
適切に登録されると、インフラストラクチャは特定のプロジェクトのすべてのSIP コールに対してHTTPリクエストを送る。これは、SIPコールの進捗をトラッキングし、エラーが発生した場合に 対処するために有用である。期待してほしい:
少なくとも1つ
callCreatedイベント・パー・コール少なくとも1つ
callDestroyedイベント・パー・コール未定義の数
callUpdatedイベント/コール未定義の数
muteForcedイベント/コール
コール・クリエイト
エンドポイントは、作成されたSIPコールごとに以下のJSONを受け取る:
{
"sessionId": "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
"applicationId": "123456",
"event": "callCreated",
"timestamp": 1470257688309,
"call": {
"id": "<conference-id>",
"connectionId": "<sip-ot-connection-id>",
"createdAt": 1470257688143
}
}
参照 JSONプロパティ を参照されたい。
更新された電話
各SIPコールの状態が更新されると、エンドポイントは以下のJSONを受信する:
{
"sessionId": "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
"applicationId": "123456",
"event": "callUpdated",
"state": "HANGUP",
"timestamp": 1470257688309,
"call": {
"id": "<conference-id>",
"connectionId": "<sip-ot-connection-id>",
"createdAt": 1470257688143
}
}
参照 JSONプロパティ を参照されたい。
破壊されたコール
エンドポイントは、各SIPコールが終了するときに、以下のJSONを受信する:
{
"sessionId": "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
"applicationId": "123456",
"event": "callDestroyed",
"reason_code": "400",
"reason_message": "Bad Request",
"timestamp": 1470257688309,
"call": {
"id": "<conference-id>",
"connectionId": "<sip-ot-connection-id>",
"createdAt": 1470257688143
}
}
参照 JSONプロパティ を参照されたい。
ミュート強制
強制ミュートモデレーションイベントによってSIP呼がミュートされると、エンドポイントは 以下のJSONを受け取る:
{
"sessionId": "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
"applicationId": "123456",
"event": "muteForced",
"timestamp": 1470257688309,
"call": {
"id": "<conference-id>",
"connectionId": "<sip-ot-connection-id>",
"createdAt": 1470257688143
}
}
参照 JSONプロパティ を参照されたい。
を設定しなければならないことに注意してください。 observeForceMute オプション true)を使用してSIP接続を作成し、強制ミュートモデレーションイベントを観察させる。
SIPモニタリング・イベントのJSONプロパティ
JSONオブジェクトには以下のプロパティが含まれる:
sessionId-- このイベントに関連付けられたセッションIDapplicationId-- このイベントに関連するプロジェクト IDevent-- callCreated | callUpdated | callDestroyed | muteForcedreason_code-- に対してcallDestroyedイベントを開催する、reason_codeは以下のいずれかに設定されている:- A 標準SIPレスポンスコード SIPハンドシェイクのエラーをキャプチャする。
- 700 -- "Normal Clearing" (通常のクリア) -- この原因は、呼に関係するユーザーの1人が呼のクリアを要 求したため、呼がクリアされていることを示す。
- 703 -- "Unexpected Clearing" (予期しないクリア) -- この原因は、呼が予期せずクリアされたことを示す。
- 704 -- "Media Timeout" -- このコードは、SIPブリッジが他のSIPエンドポイントからRTPトラ フィックを受信できなかったことを示す。
- 705 -- "Max Duration" -- 通話が最大継続時間に達した。
- 706 -- "Max Inactive" -- 呼が最大の非アクティブ時間に達した。
reason_message-- に対してcallDestroyedイベントを開催する、reason_messageは、呼が破棄された理由を表す文字列である。state-- に対してcallUpdatedイベントを開催する、stateは以下のいずれかに設定されている:DIALING-- SIPコールが開始されたRINGING-- SIPコールは現在呼び出し中ですON_HOLD-- SIPコールは保留中ですACTIVE-- SIPコールが応答され、現在進行中である。HANGUP-- 完了したSIPコール
timestamp-- イベントのタイムスタンプ。Unixのエポックからのミリ秒単位。call-- 以下のプロパティを含む、接続を定義するオブジェクト:id-- カンファレンスIDconnectionId-- SIPクライアントのコネクションIDcreatedAt-- 呼び出しが作成されたときのタイムスタンプ値(Unixエポックからのミリ秒単位)。
セキュリティへの配慮
SIPサーバでSIPインタフェースを使用する場合、Vonageが推奨するベストプラクティスがいくつかあります。あなたのサーバーで受信されたSIPコールが正当なものであることを認証・認可し、すべてのシグナリングとメディアを暗号化するメカニズムを提供することで、起こりうる攻撃を軽減しようとしています:
- 通信傍受の可能性を避けるため、TLSを使用し、シグナリングにセキュアコール(SRTP)を有効にする。
- サーバーでSIP認証を有効にする。そうしないと、あなたのSIP URIを知っている人は誰でも、あなたのサーバーにコールを送ることができます。
お問い合わせ その他ご質問があれば
技術詳細
RFC3550(RTP/RTCP)のサポート: メディアトラフィックは、暗号化(SRTP)または非暗号化(プレーンRTP) が可能である。暗号化の場合、DTLSとSDESの両方のプロトコルに対応する。
コーデック対応: Vonage SIPゲートウェイは、OPUS、G.711、G.722オーディオコーデック、H.264、VP8ビデオコーデックをサポートしています。SIPビデオは480p、800kbpsに制限されています。
シグナリング: Vonage SIPゲートウェイは、UDP、TCP、およびTLS上のRFC 3261(SIP)をサポートしています。特定の拡張子に関する情報やサポートが必要な場合は、Vonageにお問い合わせください。
Vonage SIP ゲートウェイは、Vonage SIP ゲートウェイによって開始された SIP ダイアログの一部でない限り、サードパーティ SIP プラットフォームから来る SIP メッセージを拒否します。Vonage SIP ゲートウェイで開始された通話は、次のいずれかを使用して保留にすることができます。 re-INVITE を持つ。 sendonly/inactive SDPまたは re-INVITE をポート0としてSDPに含める。
その他の考慮事項 アーリーメディアは無効。
よくあるご質問
SIPとは?なぜSIPが重要なのですか?
セッション開始プロトコル(Session Initiation Protocol: SIP)は、マルチメディア通信セッションのシグナリングと制御のための通信プロトコルである。SIPの最も一般的なアプリケーションは、インターネットプロトコル(IP)ネットワークを介した音声通話やビデオ通話、インスタントメッセージングなどのインターネット電話である。
この例では、セッションからサードパーティのSIPサーバーへの呼を確立するた めに使用される。通話が確立されると、RTPプロトコルを使用して音声(およびビデオ(含まれ ている場合))が送信される。
SIPとPSTNの違いは何ですか?VonageはPSTNゲートウェイを提供していますか?
PSTNは伝統的な電話ネットワークである。PSTNはIPネットワークではないのでSIPは使わないが、Nexmoのような多くのプロバイダーはSIPプロトコルをPSTNプロトコルに変換するゲートウェイを持っている。そうすることで、IP経由のSIP通話が電話通話に変換されます。
実際的には、Vonage Video APIがPSTNコールをサポートしていなくても、SIPコールをサポートすることで可能になります。そこから先は、SIPコールをPSTNコールに変換するプロバイダーを見つける問題です。
SIPインターコネクト機能を使って一般電話へ通話できますか?
Vonage SIPインターコネクトにより、パートナーはあらゆるSIPエンドポイントにコールを開始することができます。通常の電話との間で通話を発信/受信するには、顧客側でSIPコールを携帯電話/固定電話ネットワークで使用されるプロトコルに変換するゲートウェイが必要です。
通常の電話番号(PSTN)からのダイヤル発信やダイヤル着信を処理する方法はありますか?
SIPインターコネクトを使用すると、セッションから任意のSIP宛先にダイヤル発信できます。さらに、SIPゲートウェイ(自社またはサードパーティ)を設定して、通常の電話番号にダイヤル発信することもできます。
SIP Interconnect APIは着信SIPコールをサポートしていませんが、お客様はSIPゲートウェイ(自社またはサードパーティ)を使用して、通常の電話から受信した着信コールとVonageから発信されるダイヤル発信SIPコールをブリッジすることで、通常の電話(PSTN)からのダイヤル着信を実装することができます。
SIPインターコネクトはビデオの送信をサポートしていますか?
はい。 video フラグ true を使用してSIPコールを開始する場合。 REST APIメソッド.SIPビデオは480p、800kbpsに制限されている。
WebRTCエンドポイントとSIPエンドポイントでは、知覚される音質に顕著な違いがありますか?
期待されるのは、SIPエンドポイントでの待ち時間は増えるものの、同じ品質であることだ。
アーカイブ機能はSIPインターコネクトでどのように機能するのですか?
アーカイブ機能は、WebRTCセッションで現在行われているのとまったく同じように機能する。SIPオーディオ・ストリームとビデオ・ストリームを含め、最大16のビデオ・ストリームと最初の50のオーディオ・ストリームがアーカイブの一部となる。
ユーザーはIVRをどのように操作するのですか?ウェブ/モバイルアプリにダイヤルパッドはありますか?
REST API を使用して DTMF 信号を SIP クライアントに送信し、対話型音声応答(IVR)システムをサポートできます。以下を参照してください。 DTMF信号の送信.
SIPインターコネクトはどのSIPサーバーと互換性がありますか?
最も一般的な通信機器(ACME packet、Broadsoft)、一般的なSIPプラットフォーム(Nexmo、その他)、最も一般的なオープンソースSIPサーバー(freeswitch)との相互運用性をテストしました。すべてのSIPサーバーとの相互運用性を保証することは不可能ですが、失敗の可能性を減らすために、SIP拡張/機能の使用を制限するようにしています。これまでのところ、新しいSIPサーバーと相互運用するために私たちのソリューションを変更する必要はありませんでした。
セッションに接続しているSIPクライアントとの通話を切断するにはどうすればよいですか?
- 既存のクライアントAPIを使用する - モデレーター権限でセッションに接続されているウェブ(JavaScript)クライアントは、SIPクライアントを含む他のクライアントにセッションからの切断を強制することができる。
- サーバー側のモデレーションにREST APIを使用する - WebRTCクライアントがモバイルデバイス上にある場合、または顧客がクライアントにモデレーター権限を与えたくない場合、アプリケーションサーバーは接続中のクライアントにHTTP DELETEを発行し、サーバー側から強制的に切断することができます。