Dial

{
  "verb": "dial",
  "actionHook": "/outdial",
  "callerId": "+815099990004",
  "answerOnBridge": true,
  "srtpEncryption": "sdes",
  "dtmfCapture": ["*2", "*3"],
  "dtmfHook": {
    "url": "/dtmf",
    "method": "GET"
  },
  "amd": {
    "actionHook": "/answeringMachineDetection",
    "disconnectOnAMD": true,
  },
  "target": [
    {
      "type": "phone",
      "number": "+815099990005",
      "trunk": "MyCarrier"
    },
    {
      "type": "sip",
      "sipUri": "sip:815099990001@sip.carrier.example.net",
      "auth": {
        "username": "foo",
        "password": "bar"
      },
      "proxy" : "sip:192.0.0.1:5060"
    },
    {
      "type": "user",
      "name": "hanako@sip.example.com"
    }
  ]
}

上の例が示すように、dial コマンドを実行すると、1つ以上の発信通話の試行を行い、親通話にブリッジされる新しい通話を1つ作成しようとします。target プロパティには、同時に発信を試みる通話先の配列を指定します。

target 配列に複数のエンドポイントを指定した場合、すべてのターゲットに同時に発信され(いわゆる「simring」や「blast outdial」と呼ばれるものです)、最初に応答したエンドポイント(または、任意で confirmHook プロパティに指定した着信スクリーニングアプリケーションを最初に完了した通話)に接続されます。

発信できるエンドポイントには、いくつかの種類があります。

• 電話番号 -- この発信試行は、設定済みのキャリアを通じて送出されます
• お客様のサブドメインに直接登録している WebRTC または SIP クライアント
• SIP URI(および必要に応じて認証パラメータ)で識別される SIP エンドポイント
• Microsoft Teams ユーザー

パラメータ

同時に発信する最大10件の 通話先 の配列です。
最初に応答した相手(またはエンティティ)が発信者に接続され、残りの発信先は切断されます。

通話終了時に呼び出す Webhook です。この Webhook には、発信試行の結果を示す プロパティ が含まれます。

留守番電話検出 (AMD) を有効にします。詳細は dial Function の amd プロパティを参照してください。

true の場合、Wipple CPaaS はブリッジされた通話のメディアをメディアサーバーから解放しません。
デフォルト: false。

true に設定すると、発信先の番号が通話に応答するまで着信通話は呼び出し中のままとなり、応答した時点で着信レグに 200 OK が送信されます。
false の場合、発信通話が発信されると同時に着信通話は即座に応答されます。
デフォルトは false です。

発信者/着信側へ送出する音声信号の強度を増減させるデシベル数を示す文字列または整数値です(例: "-6 dB")。これはメインのトラックにのみ適用され、dub のトラックには適用されません。

発信先の番号に表示される、発信者の電話番号です。
発信者番号は有効な E.164 形式の番号でなければなりません。
デフォルトは着信通話の発信者番号です。

発信 INVITE でオファーするコーデック名を優先順に指定します(例: ["G722", "PCMU"])。名前の大文字・小文字は区別されません。
省略した場合、Wipple CPaaS は着信レグのコーデックを先頭に置いたデフォルトのコーデックをオファーします。これにより、ブリッジされた通話の両レグが同じコーデックを使用し、メディアをメディアサーバーから解放できるようになります。
いずれかの名前がメディアサーバーでサポートされていない場合、リスト全体が無視され、エラーがログに記録され、アカウントにアラートが書き込まれ、デフォルトのコーデックネゴシエーションが使用されます。

発信先の番号が応答してから通話が接続されるまでの間に、着信側でアプリケーションを実行するための Webhook です。
これにより、発信者が発信先に情報を提供し、発信先が応答する前に通話を拒否する機会を与えることができます。
特定の通話先ごとに異なるアプリケーションを実行したい場合は、ネストされた target オブジェクトに 'url' プロパティを指定できます。

発信通話が呼び出し中の間に発信者へ再生する、カスタム音声またはリングバックの .wav または .mp3 音声ファイルを指定する URL です。

DTMF シーケンスを表す文字列の配列です。検出されると、設定された dtmfHook を介して通話中にアプリケーションへ通知がトリガーされます。

dtmfCapture のエントリが一致したときに呼び出す Webhook です。
これは通知のみであり、応答は期待されません。必要なアクションは REST の updateCall API を介して実行する必要があります。

発信通話に追加の音声トラックを加えるための、ネストされた dub Function です。

true の場合、Wipple CPaaS は自身を通話のメディアパスから完全に外すよう re-INVITE を試みます。詳細は 後述 を参照してください。
デフォルトは false です。

着信通話の P-Asserted-Identity および Privacy ヘッダーを発信レグへ転送するかどうかを制御します。 デフォルトは true です。

発信通話の試行に適用する任意の SIP ヘッダーを含むオブジェクトです。

ネストされた listen アクションです。通話の音声が WebSocket 接続を介してリモートサーバーへストリーミングされます。

発信した通話で SIP REFER を受信したときに呼び出す Webhook です。
アプリケーションが REFER を受け入れて処理する場合、Webhook アプリケーションはボディなしの HTTP ステータスコード 200 を返す必要があり、Wipple CPaaS は SIP 202 Accepted を送信します。
それ以外の場合、HTTP の非成功ステータスを返すと、Wipple CPaaS は同じステータスコードの SIP レスポンスを REFER に対して送信します。

Wipple CPaaS は 202 Accepted を送信した後、それ以上の処理は行いません。新しい通話を発信してもう一方のレグをブリッジするのは、サードパーティアプリケーションの責任です(通常は REST API を使用します)。

sip ターゲット への発信通話で暗号化メディア (SRTP) を要求します。
指定可能な値: sdes、dtls。

• sdes — SDP オファー内の SDES crypto 属性(a=crypto 行を伴う RTP/SAVP プロファイル)で SRTP キーをネゴシエートします。LiveKit などの SIP エンドポイントはこれを想定しています。
• dtls — DTLS-SRTP で SRTP キーをネゴシエートします。
  sips: / transport=tls の sipUri と組み合わせることで、シグナリング (TLS) とメディア (SRTP) の両方が暗号化されます。sips: スキームがシグナリングの TLS を制御し、srtpEncryption がメディアの暗号化を制御します。
  省略した場合、メディアは暗号化されずに送信されます(RTP/AVP)。sip ターゲットにのみ適用されます。

通話の最大長(秒)です。

呼び出し無応答のタイムアウト(秒)です。
デフォルトは 60 です。

ネストされた transcribe アクションです。通話が文字起こしされます。

ターゲットの種類

phone

プロビジョニング済みのキャリアのいずれかを使用して、電話番号に通話を送ります。次のプロパティが利用できます。

sip

SIP URI に通話を送ります。SIP トランキングプロバイダーがユーザー名/パスワード認証を要求する場合は、auth プロパティに認証情報を指定します。 次のプロパティが利用できます。

user

登録済みの WebRTC または SIP ユーザーに通話を送ります。次のプロパティが利用できます。

teams

Microsoft Teams 連携が設定されている場合、Teams ユーザーへ発信できます。次のプロパティが利用できます。

ターゲットの種類の一部として任意で指定できる confirmHook プロパティは、発信通話が応答されたときに呼び出される Web コールバックです。このコールバックは、着信通話へブリッジする前に発信通話上で実行されるアプリケーションを返す必要があります。アプリケーションの完了時に発信通話が安定した接続状態のままであれば、2つの通話がブリッジされます。

注意

confirmHook を使うと、着信スクリーニングアプリケーション(例:「○○さんから着信があります。拒否するには 1 を押してください」)を簡単に実装できます。

actionHook のプロパティ

dial コマンドの終了時に呼び出される actionHook には、次のプロパティが含まれます。

amd.hook のプロパティ

この Webhook は、amd プロパティが含まれており、Wipple CPaaS が着信側の種類(人間または機械)を判定したか、トーンまたはビープ音を検出したときに呼び出されます。

exitMediaPath

exitMediaPath の目的は、メディアパスが Wipple CPaaS システムにまったく触れないことが重要なユースケースをサポートすることです。一般的なユースケースは、発信者が電話でクレジットカード情報を伝える、人間のオペレーターやクレジットカードシステムへ通話を転送する必要がある場合です。PCI に準拠した取引を行うには、この会話が録音・保存されたり、いかなる形でも Wipple CPaaS システムに到達したりしないようにする必要があります。exitMediaPath プロパティを使用して dial Function を実行することで、これが保証されます。

proxy

ターゲットに proxy 値を設定すると、Wipple CPaaS はこれを発信 INVITE の SIP プロキシとして使用します(例: sip:192.168.0.1:5060)。

srtpEncryption

デフォルトでは、Wipple CPaaS は発信先の sip ターゲットへ暗号化されていない RTP でメディアを送信します。発信レグで暗号化メディア (SRTP) を要求するには、srtpEncryption を sdes に設定します。Wipple CPaaS は SDP 内で a=crypto の SDES キーを伴う RTP/SAVP プロファイルをオファーします。

これはシグナリングの暗号化とは独立しています。sipUri の sips: スキーム(または ;transport=tls)が SIP シグナリングを TLS 経由にするものであり、srtpEncryption がメディアを暗号化するものです。LiveKit などのエンドポイントで要求されるように両方を保護するには、sips: URI と srtpEncryption を併用します。

{
  "verb": "dial",
  "answerOnBridge": true,
  "srtpEncryption": "sdes",
  "target": [
    {
      "type": "sip",
      "sipUri": "sips:1234567890@your-project.sip.livekit.cloud:5061;transport=tls"
    }
  ]
}

注意

srtpEncryption は sip URI ターゲットにのみ適用されます。phone、user、teams ターゲットには効果がありません(キャリアの場合は、代わりにキャリアの SIP ゲートウェイ側で SRTP を設定してください)。