Call flows

This section describes the RTP connections and sequence of SIP messages between the gateway and Voice Platform for different types of calls.

Legend

This legend describes symbols and terms used in the call flows:

Inbound call

This call flow shows the sequence of SIP messages that happen in an inbound call. See Legend for an explanation of symbols.

The sequence of events is:

  1. The call is connected and party A is now sending audio through the gateway to Voice Platform.
  2. The VoiceXML application is started and Voice Platform sends audio, for example, the first prompt, to party A.

Remote hangup of inbound call

This call flow shows a remote hangup. See Legend for an explanation of symbols.

The sequence of events are:

  1. The call is connected. Voice Platform runs the VoiceXML application, plays and gets audio to and from party A via the gateway.
  2. Party A hangs up. The gateway gets the telephony remote-hangup event.
  3. The gateway tears down its telephony connection and stops sending audio to Voice Platform. It sends a BYE to terminate the RTP connection.
  4. Voice Platform terminates the VoiceXML application and stop sending audio. The RTP connection is terminated.

Blind transfer

This call flow shows the sequence of SIP messages that happen in a blind transfer. The telephony connection (party A—gateway) is not shown for simplicity.

In a blind transfer, party A calls Voice Platform and requests a transfer to the called party C. Voice Platform responds by sending a REFER message back to party A with party C's contact information. If party A responds with either a 200 OK or 202 ACCEPTED message, the transfer is considered complete and Voice Platform disconnects from the call.

See Legend for an explanation of symbols.

The sequence of events is:

  1. The call is connected. Voice Platform runs the VoiceXML application, plays and gets audio to and from party A via the gateway.
  2. Voice Platform initiates a blind transfer and stops sending audio to party A.
  3. The gateway now stops sending audio to Voice Platform. The RTP connection is terminated.

Bridged transfer with gateway forking

This call flow shows the sequence of SIP messages that happen in a bridged transfer when the gateway supports audio forking, and the Voice Platform is configured to receive forked audio from the gateway. See Legend for an explanation of symbols.

The sequence of events is:

  1. The call is connected. Voice Platform runs the VoiceXML application and initiates a bridged transfer. It plays transfer audio if any is specified.
  2. Voice Platform makes an outbound call to party C. It sends a null medium endpoint (m0) so party C can’t send any audio back to Voice Platform.
  3. If transfer audio was enabled, Voice Platform now stops sending audio to party A.
  4. Voice Platform starts bridging party A to party C. Because Voice Platform is configured to receive forked audio from the gateway, it sends its media endpoint to the gateway, along with party C’s.
  5. Voice Platform bridges party C to party A.
  6. Party A and C are now bridged in the gateway. Since Voice Platform monitors party A by default, audio from party A is also sent to Voice Platform for hot word recognition. If whole call recording is enabled, the recording contains party A’s audio.

Bridged transfer without gateway forking

This call flow shows the sequence of SIP messages that happen in a bridged transfer when the gateway doesn’t support audio forking. See Legend for an explanation of symbols.

The sequence of events is:

  1. The call is connected. Voice Platform runs the VoiceXML application and initiates a bridged transfer. It plays transfer audio if any is specified.
  2. Voice Platform makes an outbound call to party C. It sends a null medium endpoint (m0) so party C can’t send any audio back to Voice Platform.
  3. If transfer audio was enabled, Voice Platform now stops sending audio to party A.
  4. Voice Platform starts bridging party A to party C. Because Voice Platform isn’t configured to fork audio using RTP bridging, Voice Platform sends only party C’s media endpoint to the gateway.
  5. Party A is now sending audio to party C. The RTP connection between A and Voice Platform still exists but no RTP packets are being transmitted.
  6. Voice Platform bridges party C to party A.
  7. Party A and C are bridged in the gateway. Since party A doesn’t send any audio to Voice Platform, hot word recognition isn’t possible. If whole call recording is enabled, the recording doesn’t contain any audio from party A during the transfer.

Bridged transfer with RTP bridging

This call flow shows the sequence of SIP messages that happen when the gateway doesn’t support audio forking, but Voice Platform is configured to fork audio with RTP bridging. Voice Platform sets up two RTP connections, one to bridge the parties, and the other to receive audio during the bridge.

Though mNA and mNc represent general media endpoints on Voice Platform, in reality these are endpoints on the Telephony Session service. See Legend for an explanation of symbols.

The sequence of events is:

  1. The call is connected. Voice Platform runs the VoiceXML application and initiates a bridge transfer. It plays transfer audio if any is specified.
  2. Voice Platform makes an outbound call to party C. It sends a second media endpoint, mNc, so party C can send audio back to Voice Platform.
  3. Party C now sends audio to Voice Platform.
  4. Party C has answered. If transfer audio was enabled, Voice Platform now stops sending audio to party A.
  5. Voice Platform starts bridging party A to party C. Because Voice Platform is configured to use RTP bridging, it tells party A to send audio to party C and also to Voice Platform for hot word recognition. (Voice Platform listens to party A by default.) If whole call recording is enabled, the recording contains party A’s audio.
  6. Voice Platform bridges party C to party A.

Bridged transfer with gateway forking and far-end dialog

This call flow shows the SIP messages that happen in a bridged transfer when the gateway supports audio forking, and the Voice Platform is configured to receive forked audio from the gateway. The application also specifies a far-end dialog. See Legend for an explanation of symbols.

Part 1

This part of the call flow shows the sequence up to executing the far-end dialog:

The sequence of events is:

  1. The call is connected. Voice Platform runs the VoiceXML application and initiates a bridge transfer. It plays transfer audio if any is specified.
  2. Voice Platform makes an outbound call to party A. It sends a null medium endpoint (m0) so party A can’t send any audio back to Voice Platform.
  3. Party A stops sending audio to Voice Platform.
  4. Voice Platform makes an outbound call to party C and specifies its media endpoint so party C can send audio back to Voice Platform.
  5. Party C now sends audio to Voice Platform.
  6. Party C has answered. If transfer audio was enabled, Voice Platform now stops sending audio to party A. It starts playing audio to party C to execute the far-end dialog.

Part 2

Here’s the rest of the call flow:

The remaining sequence of events is:

  1. The far-end dialog has ended. Voice Platform stops sending audio to party C. If whole call recording is enabled, the recording contains party C’s audio during the far-end dialog part of the call.
  2. Assuming that the result of the far-end dialog was to connect, Voice Platform starts bridging party C to party A.
  3. The gateway now sends audio from party C to party A.
  4. Voice Platform bridges party A to party C. Because Voice Platform is configured to receive forked audio from the gateway, Voice Platform also sends its media endpoint to the gateway.
  5. Party A and C are now bridged in the gateway. Since Voice Platform monitors party A by default, audio from party A is also sent to Voice Platform for hot word recognition. If whole call recording is enabled, the recording contains party A’s audio.

Bridged transfer with gateway forking and far-end hot word

This call flow shows the SIP messages that happen in a bridged transfer when the gateway supports audio forking, and the Voice Platform is configured to receive forked audio from the gateway. The application also enables far-end hot word on party C. See Legend for an explanation of symbols.

The sequence of events is:

  1. The call is connected. Voice Platform runs the VoiceXML application and initiates a bridge transfer. It plays transfer audio if any is specified.
  2. Voice Platform makes an outbound call to party C. It sends a null medium endpoint (m0) so party C can’t send any audio back to Voice Platform.
  3. If transfer audio was enabled, Voice Platform now stops sending audio to party A.
  4. Voice Platform bridges party A to party C.
  5. Party A sends audio to party C. Though an RTP connection is established between party A and Voice Platform, no audio is sent to Voice Platform.
  6. Voice Platform bridges party C to party A. Because Voice Platform is configured to receive forked audio from the gateway, it also sends its media endpoint to party C.
  7. Party A and party C are now bridged. Because far-end hot word is enabled, Voice Platform monitors party C for hot word recognition. If whole call recording is enabled, the recording contains audio from party C, as well as party A.