Software Overview

The SIP software provides User Agent Client (UAC), User Agent Server (UAS), and Location Server registration functionality. The implementation in this release has the following key attributes and features.

With a Matrix Controller implementation, SIP software is independent of hosts and line cards. This feature enables partners to upgrade to the next generation of SIP software and IP Network Interface cards independently.

UPDF allows for seamless protocol interworking, whether it entails various IP protocols (SIP endpoint to an H.323 endpoint) or IP-to-PSTN signaling.

The SIP software gets the RTP Payload Type and Payload size from the Route Table or Route Control message. If the type and size are not specified in either of those, the SIP software uses the IP Network Interface defaults.

The User Agent communicates with Layer 4 and the IP Network Interface card to perform SIP-controlled operations. The User Agent communicates with Layer 4 over a TCP/IP socket, and uses UDP or TCP to communicate externally with other SIP devices.

SIP software allows a Excel partner application to work with the Excel platform to provide services in the IP Services Node. Existing partners with applications that provide circuit node services can support SIP with minimal application changes.

The INVITE method is used to establish media sessions between User Agents. The RE-INVITE message permits the Excel platform to change parameters of an existing or pending call. For example, the RE-INVITE message is used with Session Timers to allow the Excel platform to regularly "ping" the far end to ensure that they are active.

Important! It is not possible to change the codecs (COder-DECoders) at runtime using the RE-INVITE message.

SIP Session Timers are an extension of SIP RFC 2543 which allows a periodic refreshing of SIP sessions using the RE-INVITE message. The refreshing allows both user agents and proxies to determine if the SIP session is still active.

In addition, the SIP software supports response code 422.
Responses in the SIP Support and Compliance Appendix.

Use the following TLVs in the VoIP Protocol Configure (0x00EE) message to implement this feature:

See the following for more information on SIP Session Timers including sample call flows:

Early media is the ability of two SIP User Agents to communicate before a SIP call is actually established. Typically, this scenario occurs when the called party is a PSTN gateway. Before the call is set up, the gateway might provide in-band tones or announcements that inform the caller of the call progress.

Early media can involve the transfer of media from caller to callee. Within the PSTN, forward channels can be established to convey DTMF signaling to select a final destination to call. This feature can be used to access Interactive Voice Response (IVR) systems "behind" 800 numbers.

• converts the SS7 Call Progress (CPG) message to a 183 response message with SDP.

When the called party wishes to send early media to the caller, the called party sends a 183 response to the caller. That response contains the SDP. When the caller receives the 183 response, it suppresses any local alerting of the user (for example, audible ring tones or pop-up window) and plays out media that it receives.

If the call is ultimately rejected, that called party generates a non-2xx final response. When the caller receives this response, the caller stops playing out or sending media. If the call is accepted, the called party generates a 2xx response and sends that to the caller. Media transmission continue as before.

See the PPL Event Request message (Event ID 0x001F) which is used to generate early media.

The Excel platform supports delayed media to allow interworking with third party call control applications (3PCC).

• Delayed media is implemented for inbound calls. That is, the Excel platform can accept a delayed media call but does not generate one.

• The Excel platform accepts INVITE messages with SDP or without SDP or with held SDP.

• Delayed media is not supported for bearer-free calls. It is supported for bearer calls only.

Excel has implemented SIP Authentication which includes protective measures to prevent an active attacker from modifying and replaying SIP requests and responses.

SIP authentication enables the Excel platform to validate legitimacy of the subscribers. It is like any login/password based scheme. It ensures that only valid users can make calls through the Excel platform.

The same cryptographic measures that are used to ensure the authenticity of the SIP message also serve to authenticate the originator of the message. SIP extends the HTTP WWW Authenticate and Authorization header field and their Proxy- counterparts to include cryptographically strong signatures.

The enhancements include support for both authentication and authorization using digest and basic.

The host uses the PPL Event Request message with event ID (12, 0x0C) to authenticate incoming SIP calls.

Third-party call control enables a SIP entity to be in control of session signaling while the media is exchanged between other entities. In some situations, the controller will not want to continue monitoring (controlling) the signaling of the session. Instead, the controller will want the other entities to continue the session independently. At this point, the controller requires a mechanism to transfer SIP sessions to another entity.

To provide session transfer functionality, the REFER method was defined. One SIP entity instructs another to perform a certain action. For example, the REFER method instructs a server to send a specific request a certain URL.

The NOTIFY method is defined in SIP to provide asynchronous event notification. The Excel platform supports the NOTIFY method, which is typically used with the REFER method in consultative and non-consultative Call Transfer applications (IP Centrex or IP PBX).

Important! The REFER and NOTIFY methods are supported for bearer-free and bearer calls.

Refer to PPL Event Indication IDs 0x0021 and 0x0022 in Table 4-3, PPL Event Indications.

If the remote SIP end points cannot multi-unicast the RFC 2833 stream, you can use the SIP SUBSCRIBE/NOTIFY method. This feature supports sending DTMF notifications via signaling.

1. When the host issues a DTMF detection request in the DSP Service Request (0x00BD) message for a SIP call, the Excel platform tries to initiate a subscription for telephone events with the remote end point using the SUBSCRIBE method.

2. When the SIP remote end point accepts the subscription, the end point starts to report the digits in the SIP NOTIFY request.

3. The Excel platform reports these digits to the host in the Call Processing Event (0x002E) message.

4. The host can terminate a subscription by sending a DSP Service Cancel Request (0x00BE) message or by releasing the call.

5. At any time, a remote SIP endpoint can terminate an active subscription by sending a NOTIFY method with the "Subscription-State" header set to "terminated."

Prior to this feature, the Excel platform delivered a SIP 180 Ringing Response to the calling SIP endpoint as a result of the host sending a Park Channel or Connect message. At its discretion, the host could initiate the 180 Response by sending a Park Channel message to the calling endpoint’s span/channel at any time prior to issuing the Connect message. If the Park Channel message was not sent and the host issued the Connect message, the Excel platform automatically generated the 180 Response after receiving alerting or an answer from the called party. In either case, the Excel platform always sent a 180 Ringing response to the SIP calling endpoint.

With the Host Control Method of SIP 180 Provisional Response Generation feature, developers can use the Alerting Propagation Mode TLV (0x0117) in the 0x1E PPL Generic ICB in the following messages. This prevents the Excel platform from automatically generating the 180 Response to the calling SIP endpoint.

This feature allows SIP signaling to be reliably transported using the Transmission Control Protocol (TCP). TCP is a transport layer, connection-oriented, end-to-end protocol. It provides reliable, sequenced, and unduplicated bytes to a remote or local user.

This feature adds to the Excel platform’s current support of SIP signaling transport using User Datagram Protocol (UDP) transport layer.

With this feature, the Excel platform is compliant with the transport aspects of SIP RFC 3261.

This section explains how the Excel platform supports SIP using TCP, and the different scenarios involved.

Whenever a SIP User Agent Client registers with the Excel platform, the Registration message specifies the desired transport type for accessing that User Agent Client. This registered transport type takes precedence over all other mechanisms to set up the outbound transport type.

The initial Invite message that leaves the Excel platform travels over the transport type specified in the Registration’s Contact header specification. Subsequent transactions within this SIP session are allowed to switch the transport type as required.

Important! If the transport type is TCP and the SIP session fails to get established, the Excel platform will not retry the Invite message using the UDP transport.

You enable the SIP mode with a VoIP Protocol Configure message that specifies the Use Default SIP Proxy Host TLV (0x0264).

When the SIP User Agent Client is not registered with the Excel platform, the Invite message is sent to the SIP proxy specified in the Use Default SIP Proxy Host TLV. In this case, the Excel platform must select a transport type to use to send the Invite message. The default outbound transport type is UDP. You can change the default transport by sending a VoIP Protocol Configure message containing the SIP Transport Type TLV (0x027D). This message sets the initial transport type for all messages originating from the Excel platform to the outbound SIP proxy.

If you want the host application controlling the Excel platform to change the transport type for individual calls, include the SIP B Leg Transport Type TLV in the Route Control message (in the NPDI ICB 0x0033).

This TLV overrides the current setting of the outbound transport type for this call. Subsequent calls that do not contain this TLV uses the current setting of the outbound transport type

Important! The following explains what happens when connected Excel platforms have different default transport types.

Platform 1 is configured to send UDP. Platform 2 is configured to send TCP.
Platform 1 sends an Invite message to Platform 2 using UDP. If Platform 2 has to send a Re-invite message back to the Platform 1, the message uses UDP since that was the original transport type used by Platform 1 in the Invite message.

The originator of the message selects the transport type of the inbound call. Whenever an Invite message arrives, the Excel platform sends a Request for Service with Data (0x002D) message to the host. This message contains the SIP A Leg Transport Type TLV (0x2916) (in the NPDI ICB 0x0033) which specifies the transport type used in the Invite message.

If this TLV specifies that the TCP transport type is used, two additional TLVs appear in the Request for Service Data (0x002D) message (in the NPDI ICB 0x0033):

You can enable persistent sockets for Inbound and Outbound SIP sessions. Persistent sockets prevent the SIP Idle Timeout from expiring and closing the socket.

If you do not use persistent sockets, each TCP socket expires when the SIP Idle Timeout is reached. The default is 32 seconds. The host can change the default by using the VoIP Protocol Configure (0x00EE) message and sending a SIP Idle Socket Timeout TLV (0x0281) with a new value. The minimum time is five (5) seconds.

• If you want all TCP sockets for all outbound SIP sessions to be over a persistent TCP socket, enable this mode with the SIP Persistent Sockets TLV (0x027E) within a VoIP Protocol Configuration (0x00EE) message.

• If you want to have a mix of persistent and non-persistent TCP sockets, include the SIP Do Not Close Socket TLV (0x294D) in the Route Control (0x00E8) message used to initiate the Invite message. Do not issue the SIP Persistent Sockets TLV.

The Excel platform does not report the remote IP and port address to the host because the host already supplied this information when placing the outbound call.

Important! Nothing prevents the peer endpoint from closing this socket, unless the endpoint is an Excel platform.

After the host receives a Request for Service with Data (0x002D) message with the following TLVs (in the NPDI ICB 0x0033) the host determines if it will make the TCP socket persistent:

If the host determines that the TCP socket should be persistent, the host issues a PPL Event Request (0x0044) message with an Event ID of 0x29, which keeps the socket from closing.

To enable this feature, send the VoIP Protocol Configure (0x00EE) message containing the SIP Existing Socket Reuse TLV (0x0280).

When you enable this feature and a SIP message needs to be transported from the Excel platform, the Excel platform checks to determine if a TCP socket to the destination is currently open. If one is open, then that socket is used to transport the message.

With this feature, the Excel platform can send selective SIP header data to the host in the Request For Service with Data message and, if required, in the PPL Event Indication message. The Call-ID header information allows the host to uniquely identify the call with other elements in the SIP network.

Important! You should disable all additional SIP header notification if calls are being internally routed without host intervention.

1. The host application specifies what additional fields from the SIP message header that it wants to see in the Request For Service with Data message.

2. You specify the fields in the 0x027F SIP Message Information Mask in the VoIP Protocol Configure message.

3. If the Excel platform can fit all of the data in the Request For Service with Data message, it does so. (The data is formatted in the NPDI TLVs listed below these steps.)

4. If the size exceeds the maximum size that the Excel platform allows (320 bytes of NPDI data), the Excel platform sends the following:

• the Subsequent Info Status 0x2953 TLV indicating that there is more data to follow.

The Excel platform sends the additional data in the PPL Event Indications message with Event ID 0x23 - Subsequent Data. (The data is formatted in the NPDI TLVs listed below these steps.)

5. If the Excel platform sends the data in multiple messages (Request for Service and subsequent PPL Event Indication) the Excel platform adds the Subsequent Info Status 0x2953 TLV. This TLV indicates the sequence number of the message and whether it is the last message in the sequence.

6. If the data has to go into an API message, and not into TLVs, the call is rejected with the "500 Internal Server Error" response.

When the host initiates an outbound SIP call using the Route Control or Outseize Control message, the Excel platform can receive one or more provisional responses from the remote endpoint before receiving the 200 OK message.

If the call flow has both 180 and 183 responses, the Excel platform sends the host the PPL Event Indication for 180 Ringing (0x0024) and PPL Event Indication for 183 Ringing (0x001F) as indicated below.

Use the PPL Event Notification Mask (0x0282) TLV in the VoIP Configure message to configure the PPL events that you want the host to see.

The SIP software supports redundancy allowing the SIP UA to continue functioning after a Matrix Controller switchover.

In an Excel platform with redundant Matrix Controller cards, the cards themselves are physically identical.

Important! To enable SIP UA Redundancy, you must configure a shared IP address. The shared IP address is for redundancy only. All API message should be sent directly to the active matrix card’s IP address - not to the shared IP address.

All communication to the Matrix Controller cards are over this one shared IP address. You create this shared IP configuration using DHCP or BOOTP. See Redundant Matrix Controller Cards in the API Developer’s Guide: Overview for general information about redundancy on the Matrix Controller card.

The two matrix cards communicate with each other over a High-Level Data Link Control (HDLC) link. The SIP software data structures are dynamically updated from the active Matrix Controller to the standby Matrix Controller on this midplane bus so calls in the connected or answered state are maintained during a switchover. Calls in transition are dropped.

See either of the following two procedures in the Application Development chapter of the Developer’s Guide: Overview to set up the shared IP address:

This features allows host application developers to use the EXS API to write and access user name extensions in the Contact and Request Uniform Resource Identifiers (URIs) in SIP headers.

These user name extensions can be used to carry application-specific information such as PSTN trunk group information.

The Excel platform supports the reporting of Contact URIs and Request URIs as follows:

• The Contact URI user name is reported in TLV 0x292D in the Request for Service with Data message.

• The Request URI is reported in TLV 0x2954 in the Request for Service with Data message.

• You must first indicate in the SIP Message Information Mask TLV (0x027F) in the VoIP Protocol Configure message (0x00EE) that you want the Excel platform to report the Request URI information (Bit 3) and Contact URI information (Bit 5).

The following TLVs are also used to implement this feature. Refer to the Tag Length Value Blocks chapter in the API Reference.

• 0x2934 SIP Contact URI User Information Qualifier
Use this TLV to append a user-defined ASCII string to the Contact URI user name in outbound SIP calls from the Excel platform. Specifically, the ASCII string is populated in the user information of the Contact-URI header in the outbound SIP INVITE message.

When the Excel platform is in a SIP/PSTN gateway environment, you can use this TLV to report the originating trunk group information in a
PSTN-to-SIP call.

• 0x2935 SIP Contact URI Parameters
Use this TLV to receive and send Contact-URI parameters to and from host applications.

For inbound calls, this TLV carries all of the Contact URI parameters received by the SIP software in the Request for Service with Data message to host applications.

For outbound SIP calls, this TLV allows you to insert Contact URI parameters in SIP INVITE messages.

To report this TLV you must first set Bit 5 in the SIP Message Information Mask TLV (0x027F).

This section shows calls in a network architecture where the host application controls a SIP/PSTN gateway. Each figure in this section is followed by the steps and message traces to further explain the process.

Figure 4-3 Originating and Destination Trunk Groups Reported by the Excel platform

1. A call comes into the Excel platform from the PSTN for example, in an SS7 IAM message.

2. The Excel platform sends the Request for Service with Data message to the host application.

3. The host application sends the Route Control message to the Excel platform. The message could contain any or all of the following TLVs:

• 0x2957 SIP Request URI User Name Qualifer

* One or the other is included but usually not both together.

4. The Excel platform sends the SIP INVITE to the network with the enhanced URIs.

2. The Excel platform sends the host application a Request for Service with Data message that could contain any or all of the following TLVs:

3. The host application sends an Outseize Control message to a span/channel within a given destination trunk group.

4. The Excel platform sends an SS7 IAM to the PSTN network over the specified destination trunk group.

This feature allows host application developers to use the EXS API to write and access proprietary Request URI parameters that extend SIP messages for carrying application-specific information.

SIP Request URI Parameter TLV (0x2958) supports this feature for Inbound and Outbound calls, as explained below.

The Request URI Parameters TLV (0x2958) carries all the Request URI parameters, received by the Excel SIP stack in the Request for Service with Data message (0x002D) to the host application.

To report this TLV to the host, you must program the new Bit 6 in the SIP Message Information Mask TLV (0x027F) used in the VoIP Protocol Configure message (0x00EE).

In the following example, the italic text in the SIP message represents the URI parameters contained in the Request for Service with Data message (0x002D).

INVITE sip:1111;tgrp=local=tg54321@10.1.205.25:5060;
tgrp=gloabal=taglucentexcelsip5000 SIP/2.0

Contact: 2222<sip:2222;tgrp="local=tg12345"@10.1.205.15:5060;"lucent=excel=telecom">

Host application developers can use the Request URI Parameters 0x2958 TLV in the Route Control and Outseize Control messages to insert Request URI parameters in SIP INVITE messages.

In the following example, the italic text in the SIP message represents the URI parameters that the host inserted using the Route Control message (0x00E8).

The SIP software supports RFC 2833 dynamic payload type negotiation between originating and terminating SIP gateways on a per call basis.

• The SIP software supports RFC 2833 dynamic payload type negotiation in Session Description Protocol (SDP) within the SIP software.

• For outbound SIP Calls, the SIP software provides the RFC 2833 dynamic payload type in SDP as provided by the host application. If this information is not in the Outseize Control or Route Control messages, the SDP provides whatever was configured on the IP Network Interface Series 2 card.

• The host can also provide the dynamic payload type for VoIP clear channel calls. It does not matter if the SIP software or the host application controls the calls.

• For in-bound SIP calls, the SIP software will propagate the RFC 2833 dynamic payload type to the IP Network Interface Series 2 card on a per connection basis.

• The SIP software can receive SIP RE-INVITE messages from the network that change the RFC 2833 dynamic payload type. The SIP software can not initiate a SIP RE-INVITE message to change RFC 2833 dynamic payload types.

• You can still configure the RFC 2833 Dynamic Payload Type when you configure the SIP software with the Resource Attribute Configure message (0x00E3).

Use the following TLV to configure the default RFC 2833 codec type on the Network Interface Series 2 cards.

Include the Dynamic Payload Type TLV (0x01F1) in the Resource Attribute Configure message to configure the default codec type on a per module basis.

Use the Dynamic Payload Type TLV in the 0x001E PPL Generic ICB in either the Route Control or Outseize Control message to change the default RFC 2833 codec value.

Use the Digit Relay Enable TLV (0x01E2) in the 0x001E PPL Generic ICB in either the Outseize Control, Route Control, or Resource Attribute Configure message to enable or disable Digit Relay support.

Use the VoIP Terminal Capabilities (0x01EA) TLV or the 0x01F1 Dynamic Payload Type TLV in the Resource Attribute Query message to query the default RFC 2833 codec type configured for each module on the IP Network Interface Series 2 card.

Byte 12 in the VoIP Terminal Capabilities TLV indicates if the default value is supported and configurable.

You can configure the second Ethernet port on the
Matrix Controller I/O card to separate the SIP signaling traffic from the host control traffic. The host-to-Excel traffic is carried on Ethernet port A and the signaling traffic is carried on the Ethernet port B. Excel recommends this configuration.

The additional information is carried in the vendor specific area of the BOOTP response. You modify the BOOTP configuration to include new entries to carry the IP Address, Gateway IP Address, and Subnet Mask for the second physical Ethernet port.

Configuring the second Ethernet port is optional but if you enter an IP Address for Ethernet port B you must enter an associated Subnet Mask.

Important! Although a gateway IP Address may be configured for both Port A and Port B, only one is utilized. If two gateway IP addresses are configured, one for Port A and one for Port B the one specified for Port A will be used. Therefore, Excel recommends that you configure only one gateway IP Address and that it be on Port B.

If you do not configure the second Ethernet port, it is internally set to the same values configured for the first Ethernet port.

For the associated procedure, refer to Configuring Dual Ethernet Ports on IP Signaling and Matrix Controller Cards in the Application Development chapter in the Developer Guide: Overview.

The SIP/VoIP Media Parameters Synchronization feature provides a way to maintain Session Initiated Protocol (SIP) signaling in synchronization with the parameters on the following cards:

Prior to this feature, the IP Signaling Layer 3 protocol, SIP, maintained a locally cached copy of VoIP media parameters on a per-module basis. When the VoIP media cards are reconfigured through the Resource Attribute Configure (0x00E3) message, the local copy of configuration data maintained by SIP on the Matrix Controller Series 3 card remains unchanged. In this way, the SIP and VoIP media parameters become unsynchronized.

The SIP stack needs to maintain an up-to-date, locally cached copy of VoIP media parameters in order to stay in synchronization with the VoIP media parameters. In order to do so, the host initiates the SIP stack configuration message, VoIP Protocol Configure (0x00EE) with the Resynchronize VoIP Media Parameters TLV (0x0284). This TLV enables the SIP stack to resynchronize with all the VoIP modules that have been previously cached by the SIP stack. For the details of this TLV, refer to the API Reference. Converged Services Administrator users refer to the Configuring SIP section in the Converged Services Administrator User’s Guide.

Below is an example of the VoIP Protocol Configure message with the Resynchronize VoIP Media Parameters TLV (0x0284) sent by the host to ensure SIP and VoIP media parameter synchronization.

This feature allows host application developers to control the SIP response code when the CSP rejects incoming registration requests.

Prior to the release of this feature, the SIP stack sent the hard-coded 503 response code when rejecting an incoming registration.

The host developer provides a final response code that the SIP stack will send to reject a SIP REGISTER message. The PPL Event request type Reject Registration contains the SIP Response Code TLV (0x2915).

The new response can be code types 4xx, 5xx, or 6xx. Refer to the Responses section.

In order to authenticate a registration request, send a 401/407 response code in the PPL Event Request message (Authenticate Request).

If you want to reject a registration with a 423 response (Interval Too Brief) use the VoIP Protocol Configure (0x00EE) message with the Minimum Registration Duration (0x0283) TLV. Refer to SIP Registration Duration Check.

For all other rejections use the PPL Event Request message with SIP Response Code TLV (0x2915).

Below is the PPL event indication sent to the host when a REGISTER is received. The following PPL event request is the rejection (cause code 403 which is value 0x0193 in SIP Response Code TLV (0x2915).

This feature allows host developers to solicit Call-ID information for outbound SIP calls.

The SIP Call-ID is a globally unique session identifier that you can use for several purposes, including call logging and billing correlation.

The Excel SIP software reports Call-ID information for inbound calls. With this feature, the same capability is provided for outbound calls.

It is optional to report the Call-ID for an outbound SIP call. You use bit number 16 in the SIP Message Information Mask TLV (0x027F) to enable or disable the information reporting.

If this bit is set in the SIP software configuration, the software will report the Call-ID information in the ACK response to the Route Control and Outseize Control messages. The information is contained in the SIP Call ID TLV (0x2950).

The following are message traces for ACK responses to the Route Control (0x00E8) and Outseize Control (0x002C) messages.

The Call-ID information is contained in the SIP Call-ID TLV 0x2950 as highlighted below.

As a SIP Registrar, the CSP SIP stack is subject to SIP Register requests from a diverse set of endpoints. Some of these endpoints might try to refresh registrations frequently enough to cause processor and memory overload conditions on the Matrix Controller card or host application.

SIP specifications RFC2543 and RFC3261 recommend that an endpoint that tries to register for an expiration interval less than the Registrar’s configurable minimum threshold can be denied with a SIP 423 response (Interval Too Brief).

Prior to this feature, the SIP stack acted as a pass-through for all REGISTER requests. Because of this scenario, the host application was involved with the PPL Event Request handshake to generate the SIP 423 response.

This feature allows you to set a minimum registration duration threshold in the SIP stack configuration. The SIP REGISTER message that requests a lower expiration duration than the minimum duration configured is automatically rejected by the CSP with the SIP 423 response code.

The SIP 423 response generated by the CSP contains a Min-Expires header field filled with the lowest registration duration acceptable to the registrar. By being able to configure the minimum registration duration threshold, you eliminate potential processor and memory overload conditions.

This feature is enabled (that is, a check for minimum registration duration is made) only when you include the Minimum Registration Duration (0x0283) TLV in the VoIP Protocol Configure (0x00EE) message. Once enabled, to disable this feature, set the duration to a significantly high value.

You can query the Registration Minimum Duration (0x0283) with the VoIP Protocol Query (0x00EF) message.

The CSP can send a list of up to five supported codecs in an offer to an endpoint when establishing a media session. The receiving endpoint selects one codec from that list and reports the selection back in the answer message to the CSP.

• The codec list is applicable for calls that use SIP or H.323 signaling and is not for clear-channel VoIP calls. For H.323 signaling, refer to Codec List in H.323-Initiated Offers.

Without this feature, the call might not get established because the CSP could include a codec type that the endpoint will not accept.

The host application provides the codec list and sends the list in the Outseize Control message as shown in the next figure:

Use the following TLVs in the Outseize Control message to include the codec types:

The trace below shows how to nest these TLVs in the Outseize Control message. Note that the Outseize Control message cannot exceed 260 bytes.

The following is a message trace for the Outseize Control message followed by the corresponding SIP INVITE message.

Session-Initiation Protocol. A signaling protocol used for establishing sessions in an IP network. A session could be a simple, two-way telephone call, or it could be a collaborative multi-media conference session.

In SIP, an application program that sends SIP requests (See also Session Initiation Protocol). Clients may or may not interact directly with a person. Users agents and proxies contain clients (and servers).

Internet Protocol. Part of the TCP/IP family of protocols used to route messages and tracks the addresses of nodes.

Universal Protocol Data Format. A predefined data format set used by a line card to communicate to the Layer 4 and above to represent information of the network-side of the line card. This set is independent of the network-side protocol.UPDF offers a "super scale" protocol format for signaling.

See Universal Protocol Data Format.

ITU-T standard defines a set of call control, channel setup, and codec specifications for transmitting real-time voice and video over networks that do not offer guaranteed service or quality of service.

Public Switched Telephone Network

Real-Time Transport Protocol. Supports transport of real-time data like interactive voice and video over packet-switched networks.

Call processing layer of the CSP.

Transmission Control Protocol / Internet Protocol. A networking protocol that provides communication across interconnected networks.

Voice over Internet Protocol. The delivery of voice information in digital form in discrete packets rather than in the traditional circuit-committed protocols of the public-switched telephone network (PSTN).

See Integrated Voice Response.

See Signaling System Number Seven.

See Programmable Protocol Language.

Positive acknowledgment to a message

Hypertext Transfer Protocol. The protocol used by web servers and client browsers to communication.

A condition that, when met, drives a state machine from one state to another. A condition that drives a Component out of its current state by invoking an associated primitive.

In PPL, a condition that, when met, drives a state machine (PPL Component) from one state to another, by invoking an associated Primitive. In PPL files, an Event is marked by an arrow and text.

Network Protocol Data Intelligence. Also called “Interworking,” it is a software product that operates within Excel’s Call Control (Layer 4) and Services (Layer 5) call processing layers. NPDI is meant to enhance Excel’s call processing product offering by allowing call processing layers (specifically Layers 4 and 5) to perform advanced analysis, generation, and conversion of Network Signaling (NS) Layer 3 information.

See Private Branch Exchange.

Digital Signal Processor

A computer, attached to the Excel platform through an RS-232 or Ethernet link, from which you run the telecommunications application that controls the Excel platform.

Tag-Length-Value block. A standardized block that allows data to inserted in a standard way into API messages.

See Information Control Block.

Range of channels provided by T1 or E1 transmission service. A physical span is a group of channels taking up a single physical wire. A logical span is a group of channels taking up less than a single logical wire, or carried over more than one physical wire.

See Address Information Block.

UPD. User Datagram Protocol. Unreliable networking layer that sits at the same level of networking stack as TCP. Part of the TCP/IP protocol suit, UDP is used for transferring IP datagrams between host computers, where each datagram is routed through the Internet based on the destination IP address.

A 32-bit address, used in IP routing, which includes a Network address identifier assigned by a central authority and a Host ID (an end station identifier assigned by a LAN administrator).

The point in the Excel platform where a DS0 connects to a network. Also known as a "socket."

Setting up, monitoring, and tearing down calls.

RFS. A Status Message indicating that some entity is requesting service from the Excel platform.

Outgoing call setup during real-time call processing on a specific channel.

Dynamic Host Controlled Protocol

Boot protocol for TCP/IP

HDLC. A bit oriented communication protocol where control codes differ according to their bit positions and pattern.

American Standard Code for Information Interchange

A device that translates calls between an IP network and another network, typically the PSTN.

The protocol used in most local area PC networks. Typically, most Ethernet networks support data transmission speeds up to 10 Mbps, but 100 Mbps is also possible.

The bits of an Internet Protocol (IP) address used for a subnetwork.

Protocol layer of the CSP.

The Matrix Controller Series 3 card is based on Motorola’s 750 PowerPC processor (68750). It is often referred to as the Matrix Controller.

CSA. GUI-based tool used to configure, provision and monitor a Excel platform related to, for example, SIP, H.323, and VDAC Resouce Attributes.