- Voice over IP (VoIP) Enhancements

FR219 - PRACK Support

The CSP supports four provisional responses:

100 Trying

180 Ringing

182 Queued Message

183 Session Progress

You can enable the CSP to support the Provisional Response ACK (PRACK) method to send non 100 provisional responses more reliably over User Datagram Protocol (UDP). This feature is disabled by default.

Important Points Regarding this Feature

The following are the details of this feature:

The Offer/Answer model for PRACK (section 5 of RFC 3262) is not supported.

The Support/Require mode for PRACK is at the stack level and not on a call-by-call basis.

The CSP now supports the Provisional Response method to send non 100 provisional over User Datagram Protocol (UDP)

There is not indication about the presence/absence of "100rel" tag in the "Supported/Require" header to the host in the RFS, PPL EI for 180Ringing or PPL EI for 183 Session progress for the following respectively:

• Received INVITE

• 180 Ringing

• 183 Session Progress

The RFC 3262 states the following: "The UAS sending the response reliably should send provisional responses once every two and a half minutes." The SIP stack supports this standard for the 182 Queued message.

FR351 - Support for SIP INFO Message

Prior to this feature the CSP SIP stack could not generate an INFO message nor could it report an inbound INFO message.

With this feature, the SIP stack can generate the INFO message by the host and report the receipt of an INFO message to the host.

The INFO message will also supports the Subject header with read and write access.

The INFO method carries the session related control information that is generated during a session. ISUP and ISDN signaling messages used to control telephony call services are examples of session control information.

By default, inbound SIP INFO messages are not reported to the host.

This feature is supported by call agent and non-call agent calls.

FR554 - Outbound SIP Call with Call Agent Mode

Dynamic Switching Media Streams

Call Agent Mode (CAM) in the CSP provides dynamic switching of media streams on or off the CSP RTP channels with a minimal amount of SIP messages.

Inbound Calls

Prior to this feature, the CSP supported bearer on/off switching of Call Agent Mode for inbound calls only. The CSP can connect the inbound leg of a SIP call to a TDM network or to a DSP media service.

This functionality allows the caller to be connected to an operator in a PSTN network. It also allows the application of DSP services such as playing announcements to the calling (inbound) leg.

Bearer switching is based on a coupling and decoupling mechanism. Coupling associates a physical timeslot with a virtual timeslot to enable bearer-switched service. Decoupling dissociates a physical timeslot from a virtual timeslot to enable bearer-free switched service.

The bearer switching takes place whenever required with minimal interaction from the host.

Outbound Calls - New

With this feature, the CSP has the bearer on/off switching capability for outbound call legs too.

This capability is needed when the media services in the CSP (like DSP-2 card) or media transit path (like external TDM IVR or operator) is required for the called party.

A directory assistance operator is located behind a TDM switch. The initial conversation between the operator and called party is bearer-switched through the CSP. Later, the operator drops out of the call flow while connecting the calling party and the called party bypassing the bearer path from the CSP.

FR620 - Via Heading Reporting

This feature reports to the host the IP address and Port Number of the top most Via header field of the inbound SIP sessions. The information in the Via header could be of the last gateway or router to handle the call.

The host can route the outbound SIP session based on the reported Via headers.

The Via head is reported for the session-establishing the INVITE. It is not reported for session-modifying INVITEs
(Re-INVITES).

Only hostnames with length up to 80 bytes are reported. If an INVITE message with hostname length greater than 80 bytes is obtained then the SIP Header Field TLV (0x299C) itself will not be reported. But the other TLVs, SIP Header Field Container and SIP Header Field will be reported.

If port number is absent or if it is NULL then the SIP Port Number TLV will not be reported.

If port number is equal to or greater than 2147483647 then it will be reported as 7f ff ff ff.

This feature is configurable and is turned off by default.

FR626 - SIP Offer Answer for Delayed Media in Call Agent Mode

This feature enables the SIP Offer/Answer model for delayed media in Call Agent mode.

Prior to this feature, the CSP supported the Offer/Answer model for normal call scenarios as follows:

The User Agent Client (UAC) made an offer in the initial INVITE message.

The User Agent Server (UAS) generates the Answer in the 200 OK message.

In a delayed-media scenario, the roles of the UAS and UAC reverses from the normal scenario above. The UAS generates the first offer and the UAC generates the answer. The CSP now can accept and generate delayed media calls in bearer free mode.

FR627 - SIP Population of Status in Outbound NOTIFY Message

The SIP stack allows the CSP to send multiple NOTIFY messages.

The NOTIFY message follows a REFER message. If the reference is pending, then the host sends a PPL Event Request for NOTIFY with response class 1xx.

Similarly, the host sends response class 2xx if the reference was successful and 5xx or 6xx in the cases where the reference failed.

If the first PPL Event Request for the NOTIFY message has a 1xx response status, then the CSP checks for more PPL Event Request for NOTIFY messages from the host.

The CSP accepts and processes PPL Event Request for the NOTIFY message until it gets a PPL Event Request for the NOTIFY message with a final response status (2xx-6xx). Any subsequent PPL Event Request for the NOTIFY message after that will be nacked. The host can send any number of PPL Event Requests for the NOTIFY message with a 1xx response status before sending a final response.

FR666 - Refer-To Header Parameter Access

REFER is a SIP method defined by RFC 3261. The REFER method indicates that the recipient (identified by the Request -URI) should contact a third party using the contact information provided in the request.

The Refer-To is a request header field (request header) as defined by RFC 3515. It appears only in a REFER request. It provides a URL to reference.

The SIP stack in the CSP has the capability for inbound and outbound refer requests.

In addition to the Refer-To Parameters, the username, host name, and passwords are reported in a PPL Event Indication message for a Consultative REFER.

Prior to this feature, the SIP stack already supported the reporting of the username, host name, and passwords for a Blind REFER.

FR667 - PPL Event Request for RE-INVITE Message

This feature allows the CSP to support the RE-INVITE message for a Call Agent Mode call in bearer-free mode using a new PPL Event Request (0x0024). This PPL Event Request generates a Re-INVITE regardless of the call direction: incoming or outgoing.

FR669 - PPL Event Request for RE-INVITE

This feature allows the CSP to support the RE-INVITE message for a Call Agent Mode call in bearer-free mode using PPL Event Request (0x0024). This PPL Event Request generates a Re-INVITE regardless of the call direction: incoming or outgoing.

This PPL Event Request will work only if the call is in bearer-free mode or else it will NACK with a value 0x130C (Call is not in bearer-free mode.)

FR671 - SIP Subject Header in REFER

The Subject Header field is now an optional header in the REFER message. This feature allows read and write access for the Subject Header field in the REFER message.

Read access is allows the host to receive the content of the Subject Header field, if it is present in the inbound REFER message. You can configure whether or not to report the Subject Header field.

Write access allows the host to fill into the Subject Header field of the outbound REFER message. This functionality is available for Call Agent and non-Call Agent calls.

FR735 - SIP Display Name Parameter in From Header

This feature allows access to display name parameter in the From Header field in SIP methods. The display name in the From Header field will be reported to the Host for incoming request method and can be configured for specific value for an outgoing request method.

FR736 - Refer to Phone Number

This feature allows the CSP to support telephone number in an outbound REFER method.

REFER is a SIP method as defined by RFC 3261 that indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request. Refer-To is a request header field with in the REFER method as defined by RFC 3515.

Prior to this feature, the CSP supports only the SIP URL in the Refer-To header. The host had to provide the username and host name in the PPL Event Request method to generate the REFER. By default CSP fills in the port number, in case the host has not supplied it. There was no provision for the host to use a telephone number in Refer-To header.

With this feature, the CSP supports telephone number in an outbound REFER method.

Important! The telephone number supplied by the host is not validated by CSP.

FR893 - Send and Receive SIP Signals Using the Same Port

Prior to this feature, the CSP received inbound SIP signals on a specific User Datagram Protocol (UDP) port - by default it was port 5060. The receiving port could be changed at run time.

All outbound SIP signals were sent out on a UDP port allocated by the CSP when you configured SIP. This port number could be any valid (and unused) port number above 1023. The port used for outbound SIP signaling from the CSP remained constant until SIP was deconfigured.

With this feature, the CSP now sends and receives SIP signals using the same port as configured by the host. By default, the CSP uses port 5060 for all SIP traffic.

FR894 - Access To Contact Header

Contact Header

For an endpoint to endpoint call, one endpoint receives an INVITE message (in this case the CSP) and returns a 200OK response. The endpoint that sent the INVITE message uses the Contact information from the 200OK response to send the ACK message to the CSP and subsequent messages such as BYE.

Likewise, the endpoint that receives the INVITE (in this case the CSP) uses the Contact header to send future requests such as BYE. Final responses to INVITE message have to be routed back the same path.

Read and Write Access

This feature allows the host read and write access to the following fields in the contact header in the 200OK response for an INVITE message:

Contact Display Name

Contact Username

Contact Parameters

Note that the host portion cannot be changed because if it is changed, the remote endpoint would not be able to route future requests to the CSP correctly.

FR895 - Report and
Control of
P-Asserted and P-Access Network Info Headers

The CSP SIP stack can report the "Remote-Party-ID" and the "RPID Privacy" headers if present in the SIP INVITE message.

Now with this feature, the SIP stack can read and write the "Privacy" header as follows:

Privacy (Defined in RFC 3323)

and the following private headers (P-Headers):

P-Asserted-Identity (Defined in RFC 3325)

P-Preferred-Identity (Defined in RFC 3325)

P-Access-Network-Info (Defined in RFC 3455)

By default, the SIP stack does not report these P-headers. You have to enable this functionality.

The SIP stack does not modify any other SIP headers for privacy related to this feature.

FR928 - SIP 182 Queued Message

One usage of the 182 Queued message is as follows: the called party is temporarily unavailable but the server decides to queue the call rather than reject it.

When the called party becomes available, it returns the appropriate final status response.

The reason phrase might give further details about the status of the call for example, "5 calls queued; expected waiting time is 15 minutes."

The server might issue several 182 (Queued) responses to update the caller about the status of the queued call.

With this feature, the SIP stack is enhanced to allow the host to:

generate the 182 Queued message

report the receipt of the 182 Queued message to the host

This feature is supported in Call Agent and Non-Call Agent calls.

FR991 - Session Description Protocol (SDP) Pass-Through for Call Agent Mode

SDP Signaling Endpoint

The Call Agent Mode (CAM) turns the CSP into a centralized SIP call controller that allows direct flow between the external end-points.

In CAM, the CSP acts as a SIP Back-to-Back User Agent and is not only a full-fledged SIP signaling end-point (User Agent) but also a Session Description Protocol (SDP) signaling endpoint. The CSP originates and terminates SIP and SDP signaling and establishes independent signaling sessions with external endpoints.

In order to facilitate direct media flow between the external endpoints, the CSP interworks essential inbound SDP parameters into NPDI TLVs to carry this information to the host application. The reverse process occurs for outbound SDP parameters.

Any Non-Audio Media Supported

Prior to this release, the SDP processing in the CSP could handle only audio media sessions. With this release, the SIP stack is extended to provide more transparency when media capabilities are negotiated between endpoints.

This transparency comes by tunneling an essential portion of raw SDP text between the external endpoints. This approach is flexible because it allows any non-audio media session (not just T.38 fax) to get setup across the CSP. In addition, the endpoint’s media capabilities can evolve without affecting the CSP.

FR874 - H.323 Digit Collection

The H.323 Digit Collection feature will enable you to collect Dual Tone Multi-Frequency (DTMF) digits using the H.323 protocol in the CSP. DTMF digits can be received and sent by the H323 protocol and can be sent in-band or out-of-band. When this feature is implemented in the CSP, the DTMF digits, routed to Layer 4 Dialing Plan (L4 DP) using the IP network, are either in signaling or in Real Time Protocol (RTP) format. These digits will be decoded for the customer as part of their dialing plan.

Currently, the DTMF digits are internally propagated and bypassed directly to the PSTN side using the DSP Service Request message. The customer is unable to initiate the collecting of digits.

Instead of bypassing the direct propagation of digits to the PSTN side, two new configuration bytes provide enhanced digit routing in order to support digit collection. These configuration bytes support both signal and alphanumeric type applications.