Changes in Release 8.4.1 Engineering Release 10

FR1661 IPN-3 Channels OOS on Ethernet Link Failure

Prior to this feature, when the IPN-3 card lost its Ethernet connection to the data network (the network that transports VoIP RTP packets) the VoIP spans and channels associated with the IPN-3 card remains in service.

This behavior was different than how TDM line cards handled the same scenario. When the TDM span link is lost, the TDM channels are taken out of service.

This feature associates the service state of the VoIP spans and channels with state of connectivity to the IPN-3 card’s external data network. When this feature is enabled, if Ethernet connectivity to the data network is lost for three or more seconds, the VoIP spans and channels go out of service. Any active channels are purged and then brought out of service.

When Ethernet connectivity to the data network is restored for three seconds, the spans and channels come back into service.

Now IPN-3 cards and TDM line cards behave consistently.

These service state changes are made without direction from the host which is also the same behavior as TDM line cards.

Alarm

The same span alarm that is set and cleared by TDM line cards when they lose TDM connectivity are used when the IP network connectivity is completely lost on the IPN-3 card.

It is a Carrier Group Alarm with the Span Status field set to 0x01 (Receiving Red).

The CSP sends the 0x00B9 alarm when no data network connectivity is available for three seconds and cleared with a 0x00C1 message when stable network connectivity returns.

This sequence occurs individually for every span that has been assigned to the IPN-3 card.

The CSP also sends the host the DS0 Status Change API message (0x0042) for all channels showing a purge (0x73) and OOS condition for the channels. When the data network is available again, the DS0 Status change message will reflects an INS state for all channels.

The alarm and DS0 Status Change messaging is the same for the IPN-3 card and TDM line cards.

Configuration

For backward compatibility, this feature is disabled by default. You enable this feature at the board level using the following new TLV Network Failure Detection Behavior (0x2A2F).

You enable Network Failure Detection with the Resource Attribute Configure API (0x00E3) and queried with the Resource Attribute Query API (0x00E4). You address the API to the slot containing an IPN-3 card. No span/channel or IP address AIBs are used in the API for this board level configuration or query.

The following is the format of the TLV.

Byte

Description

0,1

Tag 0x2A2F Network Failure Detection Behavior

2,3

Length 0x0002

4

Reserved 0x00

5

Value[0-2] 0x00 - Spans/Channels remain INS if the data

network is unavailable (default).

 

0x01 - Spans/Channel brought OOS if data

network is unavailable.

Resource Attribute Configure Message - Example

00 12 00 E3 00 00 FF 00 01 01 01 09 00 01 2A 2F 00 02 00 01

Resource Attribute Query Message - Example

00 10 00 E4 00 00 FF 00 01 01 01 09 00 01 2A 2F 00 00

 

RTP Loopback Calls

RTP Loopback calls do not require TDM connectivity and are not supported if this feature is used because when the data network is unavailable, there is no active channels in the IPN-3 to support the loopback call scenario.

 

FR1643 SIP Multiple Refer Support

Prior to this feature, the CSP SIP stack did not support multiple REFER requests within a dialog. The SIP stack accepts and allows the host to generate multiple REFER requests within a dialog. Prior to this feature, only the last send/received refer-subscription was stored.

This feature enhances the CSP SIP to do the following:

Accept multiple REFER requests within a dialog and maintain the refer subscription information for all valid REFER requests received for up to eight refer subscriptions per call.

Allows the host to instruct the CSP to generate a NOTIFY message with the ID parameter in the Event header as per RFC 3515 section 2.4.6 and RTC 3265 section 3.1.2.

The CSP always acts as a REFER notifier. This feature supports multiple REFER only in scenarios where the CSP acts as a refer notifer.

This feature is configurable at the stack level and is disabled by default.

Configuration

To enable this feature, set bit 25 (0x2000000) in the value part of the SIP Message Information Mask (0x027F) TLV sent in the VoIP Configure message (0x00EE).

New SIP NPDI TLV - SIP Subscription ID (0x296B)

You can use this new TLV for the following two purposes:

Report the Refer Subscription to Host - This TLV is reported within the PPL Event Indication for inbound REFER request, except for the first inbound REFER request in the dialog.

Generate NOTIFY with ID Parameter - This TLV is used in the PPL Event Request to generate NOTIFY request except for the first NOTIFY for the refer-subscription.

The following is the format of the TLV.

Byte

Description

0,1

Tag 0x296B

2,3

Length 0x0001

4

Value[0] Subscription ID

0x00 - 0x07

 

The subscription ID is internally generated by the SIP stack and does not report the value of any parameter in the SIP message.

 

Important! The refer subscription ID, reported in this new TLV, is different from the value of the ID parameter in the Event head in NOTIFY message. Each valid inbound REFER shall create a refer-subscription that will store information like subscription duration, REFER CSeq and subscription state. A unique identifier (a numerical value) for each refer-subscription with in a dialog shall be created by CSP SIP stack and will be reported to host using the new TLV. So the CSeq for REFER is not reported in the PPL Event Indication for REFER, instead it is the refer-subscription identifier that is reported to host. The host shall use this identifier in the PPL Event Request to generate NOTIFY for that refer-subscription. Internally CSP shall use this identifier to select the refer-subscription and use the REFER CSeq stored to be used as the ID parameter value in the NOTIFY message.

Query

Use the VoIP Protocol Query API (0x00EF) to query the configuration status of this feature.