-
WebSockets fork SIP-to-SIP calls using G.711ulaw or G.711alaw.
-
CUBE establishes a TCP connection with the destination URL provided in a forking request. The host address that is provided in
the URL may either be an IPv4 address or a fully qualified domain name that is resolved using DNS. Once a connection is made
with a destination, it can be used for multiple forked media streams. Two media streams are created for each forked call,
one from the calling and one from the called party.
-
CUBE uses INFO messages to provide connection status information to a Unified CVP and to signal the start of a stream to the Speech
Server. Each stream is identified by a unique channel identifer.
-
CUBE initiates a WebSocket connection by sending an HTTP GET request to the Speech Server with Upgrade: websocket. If the connection is successful, the speech server responds with HTTP/1.1 101 Switching Protocols. CUBE validates the connection by matching the Accept keys (Sec-WebSocket-Accept) that are exchanged in GET and 101 messages.
-
The maximum number of WebSocket connections is based on the router platform.
-
Established WebSockets maintain a persistent connection for as long as they are being used. A WebSocket connection is closed
in either of the following ways:
-
If idle for more that 30 minutes, a WebSocket connection is closed automatically. To define a custom duration for the connection
timeout, configure connection
idle-timeout
minutes .
-
Use the clear voip stream-service connection id forced command to clear a WebSocket connection.
-
The following show commands display information about WebSockets in CUBE:
-
show voip stream-service callid
callid
—Displays detailed information about a WebSocket fork using the call ID of the original call.
-
show voip stream-service connection —Displays information about all the active WebSocket connections in CUBE.
-
show voip stream-service connection history —Displays information about closed or stale WebSocket connections in CUBE.
-
show voip stream-service connection id
id —Displays detailed information about a specific WebSocket connection in CUBE.
-
show voip stream-service server
ip:port —Displays information about WebSocket connections corresponding to a specific Speech Server IP address and port.
-
show voip stream-service statistics —Displays statistical information about WebSocket connections in CUBE.
-
show platform hardware qfp active feature sbc fork global —Displays media forking statistics that are related to all the forking instances for an active Cisco Quantum Flow Processor
(QFP) instance of CUBE.
-
show platform hardware qfp active feature sbc fork session —Displays media forking statistics specific to a fork session for an active Cisco Quantum Flow Processor (QFP) instance of
CUBE.
-
Use the clear voip stream-service statistics
command to reset the global WebSocket statistics in CUBE.
Load Balancing
CUBE supports load balancing of forked media streams across multiple WebSocket connections. Each connection to a Speech Server
can accommodate a maximum number of calls (threshold).
When CUBE receives a forking request, it assigns the media stream to one of the less busy connections to the target Speech Server.
You can configure the maximum number of calls that CUBE assigns to each connection using the command connection calls-threshold
calls . The range is 1–20 calls. We recommend that you configure the default call threshold of three calls per connection.
Consider the following scenario. The threshold for the number of calls that a WebSocket connection can handle is ten. If all
the WebSocket connections are handling ten calls each, then CUBE creates a new WebSocket connection for the incoming call.
Pause and Resume Forking
The codec that is used for a WebSocket fork must be the same as the one negotiated for the call. Consider a scenario in which
CUBE receives an initial call with codec G711ulaw. If CUBE receives a forking request (re-INVITE with START message) with G711ulaw, then CUBE starts forking. However, if CUBE receives another re-INVITE with codec G711alaw during forking, a PAUSE message is sent to the Speech Server to suspend the forked stream.
CUBE sends a PAUSE message to the Speech Server to pause WebSocket-based forking in the following scenarios:
-
A call with an ongoing forking session is placed on hold.
-
A call with an ongoing forking session receives a re-INVITE with a codec other than the previously negotiated codec—In this
scenario, codec information is available in the initial re-INVITE with the forking request.
WebSocket-based forking is resumed by sending a RESUME message to the Speech Server. The following are the prerequisites for CUBE to resume WebSocket-based forking:
The following are the scenarios in which CUBE resumes WebSocket-based forking.
-
CUBE receives re-INVITE and the codec in the forking request is same as the negotiated codec.
-
The call is placed on hold and the corresponding forking is paused. When the call is resumed, the forking is also resumed
if:
-
The newly negotiated codec is same as the one received in the re-INVITE with a forking request.
-
The re-INVITE with a forking request doesn't have any codec information, and the call-negotiated codec is either G711ulaw
or G711alaw.
Note
|
WebSocket forking can only be used for g711ulaw and g711alaw codecs.
|
-
CUBE sends a PAUSE message followed by a RESUME message even for a single re-INVITE forking request, in the following scenario. The initial re-INVITE with a forking request
doesn't contain codec information. Call negotiation codec is either G711ulaw or G711alaw. Then CUBE uses either of these codecs (for example, G711alaw) to trigger forking. If CUBE receives a midcall re-INVITE with G711ulaw, it sends PAUSE followed by RESUME message. The RESUME message contains information on the newly negotiated codec.
Note
|
|
INFO-Based Forking
Some of the primary call scenarios and the corresponding behavior for INFO-based forking include:
-
CUBE receives a Re-INVITE (with codec change, media address change or session refresh) request after the initial call is established—The
Re-INVITE is handled as for a normal call. As INFO with JSON is received in the initial call, the CUBE triggers the forking request.
-
CUBE receives a Re-INVITE after the initial call is established. INFO with JSON is received before completing the Re-INVITE transaction—As
INFO with JSON is received in the initial call, CUBE triggers the forking request.
-
Re-INVITE for codec change introduces PAUSE and RESUME into the forking scenario.
-
Re-INVITE for media address change is handled consistent to the handling of a normal call.
-
Re-INVITE for session refresh is handled consistent to the handling of a normal call.
-
CUBE successfully triggers a forking request but Unified CVP does not respond with 200 OK and retransmits INFO with JSON—CUBE
ignores the retransmitted forking request.
UPDATE Message
Unified CVP can request CUBE to update the metadata in an ongoing forking session using the UPDATE message type. The metadata for the ongoing forking
is in the JSON body of a Re-INVITE or INFO message.
Note
|
The UPDATE message is contained in the JSON body of a SIP INFO message.
|
Note
|
It's not allowed to use UPDATE message to change the forking session or connection. If a change in forking session or connection
is required, use the STOP message to stop the current forking and the START message to restart forking with the new details.
|
Alarms
Alarms are generated corresponding to the events logged for WebSocket-based forking in CUBE. Alarms are generated in the form of syslog messages for the following events:
The following is a sample syslog alarm format specific to WebSocket-based forking:
%SIP-3-STREAM_SERVICE: 1 HTTP connection failures
%SIP-3-STREAM_SERVICE: 50 TCP connection failures
%SIP-3-STREAM_SERVICE: 60 Remote WebSocket closures
%SIP-3-STREAM_SERVICE: 120 TCP closures
Note
|
By default, the syslog alarm is generated for the first instance of TCP failure, HTTP failure, Remote WebSocket closure, and
TCP closure. Thereafter, CUBE generates syslog alarms for these events after every ten occurences.
|
When you execute the command clear voip stream-service statistics , the statistics for the events TCP failure, HTTP failure, Remote WS closure and TCP closure are reset. The command show voip stream-service statistics displays these statistics.
Event Trace Logging
For WebSocket-based forking in CUBE, events are logged using the VoIP Trace and Event Trace Logging framework. While VoIP Trace logs the call events, Event Trace
logs the global events and call events.
VoIP Trace logs call events that are related to WebSocket-based forking:
-
Forking request for a call
-
Forking initiated for a call
-
Forking paused or resumed
-
Forking stopped
Event Trace logs global events that are related to WebSocket-based forking:
-
WebSocket creation
-
WebSocket closure (Due to idle timeout)
-
WebSocket closure (Due to clear command—clear voip stream-service connection id )
-
WebSocket remote connection closure (Due to Speech Services closing the WebSocket connection gracefully)
-
WebSocket TCP connection closure (Speech service outage is one of the identified causes)
-
WebSocket connection creation failure
-
Alarms. This is similar to Syslog Alarms.
The following is a sample output for Event Trace logging specific to WebSocket-based forking:
*Oct 14 07:18:10.913: CUBE_ET: TYPE = GLOBAL : WebSocket Connection creation successful for ws://10.64.86.215:8000
*Oct 14 20:25:12.160: CUBE_ET: TYPE = GLOBAL : WebSocket Connection closed locally due to idle-timeout expiry for ws://10.64.86.215:8000
*Oct 14 07:20:08.786: CUBE_ET: TYPE = GLOBAL : WebSocket Connection closed locally using clear command for ws://10.64.86.215:8001
*Oct 14 21:01:38.061: CUBE_ET: TYPE = GLOBAL : WebSocket Connection was remotely closed for ws://10.64.86.215:8002
*Oct 14 22:13:00.879: CUBE_ET: TYPE = GLOBAL : WebSocket Connection : 1 HTTP connection failures
*Oct 14 07:18:31.205: CUBE_ET: TYPE = GLOBAL : WebSocket Connection was closed over TCP for ws://10.64.86.215:8000
Server Name Indication (SNI)
WebSocket-based forking in CUBE provides support for Server Name Indication (SNI). SNI is a Transport Layer Security (TLS) extension that allows a TLS client
to indicate the name of the server that it's trying to connect with during the initial TLS handshake process. The server hostname
that is received in JSON by the WebSocket is used to configure SNI. SNI isn't set if the IP address of the host is received
in JSON. For WebSocket-based forking, SNI is always used for WebSocket forking where possible.
If CUBE uses a proxy server for setting up a WebSocket connection, then SNI is set using the hostname of the proxy server that you
configure. However, SNI isn't set if the IP address of the proxy server is configured instead of the hostname.
Common Name and Subject Alternate Name
WebSocket-based forking in CUBE supports server identity validation through Common Name and Subject Alternate Name fields in the server certificate. Common
Name and Subject Alternate Name validation is supported only when the hostname of the server is available. Common Name and
Subject Alternate Name isn't validated in WebSockets if CUBE receives the IP address of the host or proxy server.
For more information on SNI, Common Name and Subject Alternate Name, see SIP TLS Support on CUBE.
Feedback