Wipple CPaaS
メニュー
Webhook / 新規通話 (POST)

新規通話 (New Call)

POSThttps://{yourserver}/webhooks/callContent-Type: application/json

この Webhook は、プラットフォーム上で新しい通話が作成されたときに送信されます。アプリケーションレベルで設定します。

認証

  • Authorization ヘッダー (basic auth, 必須) — Basic <base64(username:password)> 形式の Basic 認証です。

リクエスト

ボディ (application/json)

このエンドポイントは CallHook を受け取ります。

  • call_sidstring必須通話の一意の識別子。
  • call_idstring必須当社サーバー上での通話 ID。
  • application_sidstring必須この通話を制御する Wipple CPaaS アプリケーションの一意の識別子
  • account_sidstring必須アプリケーションに関連付けられた Wipple CPaaS アカウントの一意の識別子
  • directionenum必須通話の方向:
    • inbound - Wipple CPaaS の外部から発信された通話
    • outbound - Wipple CPaaS から発信された通話
  • 指定可能な値: inbound, outbound
  • fromstring必須発信者番号
  • tostring必須着信側番号
  • caller_namestring必須発信者名 (判明している場合)
  • sip_statusdouble必須この通話で受信または生成された最新の SIP ステータスコード
  • sip_reasonstring必須最後のレスポンスの SIP ステータス行の reason phrase (例: Trying、OK、Busy Here)。これは RFC 3326 の Reason ヘッダーではありません。sip_reason_header を参照してください。
  • call_statusenum必須通話の現在のステータス:
    • trying - 新しい着信通話が到着したか、発信通話を送出した直後
    • ringing - 180 Ringing レスポンスを送信または受信した
    • early-media - 通話応答前にアーリーメディア接続が確立された (183 Session Progress)
    • in-progress - 通話が応答された
    • completed - 応答済みの通話が終了した
    • failed - 発信試行が失敗した
    • busy - 着信側が話中ステータスを返したため発信試行が失敗した
    • no-answer - 時間内に応答されなかったため発信試行が失敗した
  • 指定可能な値: trying, ringing, early-media, in-progress, completed, failed, busy, no-answer
  • sip_reason_headerstring任意このステータス変化を引き起こした SIP メッセージの RFC 3326 Reason ヘッダー (含まれていた場合)。含まれていない場合は省略されます。ISDN/E1 PRI トランクを収容するキャリアは、信頼できる切断原因をステータス行ではなくこのヘッダーに格納します。また、同じ SIP ステータスでも異なる原因を伴うことがあり、たとえば 503 は cause=38 (network out of order) の場合も cause=41 (temporary failure) の場合もあるため、ステータスコードだけでは通話の結果を分類できません。Q.850;cause=18 ("no user responding") を伴う 408 は、誰も応答しなかった通話であり、プラットフォームの障害ではありません。このヘッダーは、それを観測したイベント (最終的な失敗レスポンス、応答済み通話での BYE、または発信者が諦めたことによる CANCEL) のいずれかに含まれます。特に重要なのは CANCEL の場合です。487 とその Request Terminated という phrase は Wipple CPaaS 自身が生成するため、このヘッダーがなければ放棄されたすべての着信通話が同一に見えてしまいます。SIP;cause=200;text="Call completed elsewhere" によって、フォークされた分岐が競合に負けたケースと発信者が切断したケースを区別できます。解析時の注意点が 2 つあります。このヘッダーは転送中に再シリアライズされ、RFC 3326 が ; の前後に許容する任意の空白が正規化されるため、キャリアからの Q.850 ;cause=18 は Q.850;cause=18 として届きます。文字列の完全一致ではなく、寛容に解析してください。また、1 つのメッセージに複数の Reason ヘッダーが含まれることがあり、その場合はカンマ区切りで届きます。text="..." の値にカンマが含まれる可能性があるため、引用符の外側のカンマで分割してください。
  • sbc_callidstring任意通話が Wipple CPaaS に到着した時点での元の Call ID
  • originating_sip_ipstring任意通話を Wipple CPaaS に送信した IP アドレス
  • originating_sip_trunk_namestring任意通話を受信した Wipple CPaaS 上のキャリアの名前
  • local_sip_addressstring任意通話を処理しているメディアサーバーの内部アドレス
  • service_provider_sidstring任意通話を処理しているアカウントが属するサービスプロバイダーの ID
  • sipsipRequest任意通話の SIP リクエスト
  • env_varsCallHookEnvVars任意アプリケーションに設定されたアプリケーション環境変数

レスポンス

200

Function の配列からなる JSON ペイロードを含む 200 を返してください

型定義

sipRequest

  • rawstring必須SIP リクエスト全体を 1 つの文字列にしたもの。
  • headersSipRequestHeaders必須各 SIP ヘッダーをキー/値オブジェクトにしたもの
  • bodystring必須SDP を含むリクエストのボディ
  • methodstring必須SIP メソッド
  • versionstring必須SIP バージョン
  • uristring必須リクエストの SIP URI
  • payloadSipRequestPayload必須リクエストのボディ

CallHookEnvVars

アプリケーションに設定されたアプリケーション環境変数

SipRequestHeaders

各 SIP ヘッダーをキー/値オブジェクトにしたもの

SipRequestPayload

リクエストのボディ

例

リクエスト

{
  "call_sid": "d2515c3b-b79a-41a2-971a-445e769c823c",
  "call_id": "d2515c3b-b79a-41a2-971a-445e769c823c",
  "application_sid": "72c5c38f-9bba-40ce-aa83-aaa6be55e1b5",
  "account_sid": "bad98250-b34d-459d-9e90-f97dfb9bc519",
  "direction": "inbound",
  "from": "+815099990001",
  "to": "+815099990002",
  "caller_name": "Miraicom Taro",
  "sip_status": 100,
  "sip_reason": "Trying",
  "call_status": "trying"
}

レスポンス

{}