You are here: CSP Developer’s Guide: Internet Protocols > 3 IP Network Interface Series 2 Card > VoIP Resource Profiles
The IP Network Interface Series 2 card VoIP capabilities are defined by the resource profiles assigned to each IP endpoint (module). Based on the terminal capabilities of the profile, the host decides how each VoIP channel can best be provisioned.
The IP Network Interface Series 2 card has the ability to convert voice data between a circuit-and packet-switched network. Each endpoint can be configured and managed independently from one another except, they share from a common span/channel pool.
Assigning a VoIP Resource Profile
The IP Network Interface Series 2 card supports multiple profiles and the ability to configure different modules with different profiles. While this provides flexibility, it also adds complexity. The host can configure a VoIP module’s Resource Profile using the Resource Attribute Configure (0x00E3) message. Currently, this API supports the configuration of three entities:
1. Updating the default VoIP attributes of a particular VoIP module.
2. Updating the current VoIP attributes of an active VoIP channel.
3. Updating the IP Network Interface Series 2 card Gateway Mode.
Updating Default Attributes of a VoIP Module/Updating Current Attributes of a VoIP Channel
The Resource Attribute Configure (0x00E3) message is addressed to the slot of the IP Network Interface Series 2 card using the Slot Address Type (0x01) AIB. The first TLV after the AIB defines which of the entities are getting configured.
For updating entities 1 and 2 above, an Address Element (0x0009) TLV is used to specify which attributes are to be updated, the default (1) or an active channel (2). The IP Address (0x3E) AIB is used to specify which VoIP module default attributes are to be updated. The Expanded Span/Channel (0x0D) AIB is used to specify which active channel attributes are to be updated. If the Address Element (0x0009) TLV is not provided, the resource attribute will be applied to the IP Network Interface Series 2 card, rather than to a VoIP module or VoIP channel.
Updating IP Network Interface Series 2 Card Gateway Mode
For updating entity 3 above, the IP Network Interface Series 2 card Gateway Mode, the Gateway Mode TLV (0x01D0) must be present without an Address Element TLV (0x0009). The absence of the Address Element TLV indicates that the resource attribute will be applied to the IP Network Interface Series 2 card itself. Since this causes the TDM resources provisioned on the Excel platform to be changed, a IP Network Interface Series 2 card reset is necessary and performed automatically. Once the IP Network Interface Series 2 card finishes resetting and comes into service, the Resource Attribute Configure (0x00E3) message is acknowledged.
Important! Changing the Gateway Mode causes the entire IP Network Interface Series 2 card host configuration to be reset.
Updating a VoIP Module Resource Profile
The Resource Profile Assign (0x01E5) TLV has been created to configure a module’s resource profile. Similar to changing the Gateway Mode, changing a VoIP module resource profile causes its TDM resources to change, causing the IP Network Interface Series 2 card to reset, so that new resources can be allocated.
Important! Changing the resource profile on any module causes the IP Network Interface Series 2 card host configuration to be reset.
The Resource Profile Assign (0x01E5) TLV addresses the VoIP module by its module number. Since updating a VoIP module’s profile causes the IP Network Interface Series 2 card to reset, all of the modules can be reset in a single message.
The host has the flexibility to send one VoIP Resource Profile Assign TLV to assign the same resource profile to all modules or send multiple TLVs to individual modules. If any TLV is invalid, the message is negatively acknowledged (NACKED) and no action is taken. The Resource Profile Assign (0x01E5) TLV format is as follows:
Table 3-4 VoIP Resource Profile Configure TLV
Byte |
Description |
0, 1 |
Tag: VoIP Resource Profile Assign (0x01E5) |
2, 3 |
Length: 0x0003 |
4 |
Value: Data[0] Module Number |
5 |
Data[1] Profile Number |
6 |
Data[2] Force Flag |
The VoIP Terminal Capabilities (0x01EA) TLV has been created to query an IP endpoint’s terminal capabilities. The report returned is based on the resource profile assigned to the module.
The following information is provided:
• VoIP Resource Profile ID
• Maximum EC Tail Length
• Maximum Jitter Buffer Size
• Silence Suppression Support Silence Suppression (sometimes referred to as Voice Activity Detection, VAD)
• Fax Relay Support
• RFC 2833 Digit Relay Support
• RFC 2198 RTP Redundancy Support
• List of codecs supported along with their base and maximum packet rate
Below is the format of the VoIP Terminal Capabilities (0x01EA) TLV, which is queried from the Resource Attribute Query (0x00E4) message:
Important! The VoIP Terminal Capabilities can be queried by addressing either the IP Address AIB or Extended Span/Channel AIB embedded within the Address Element TLV.
Table 3-5 VoIP Terminal Capabilities TLV (0x01EA)
Byte |
Description |
0,1 |
Tag: VoIP Terminal Capabilities (0x01EA) |
2, 3 |
Length: Variable |
4 |
Data[0] VoIP Resource Profile ID |
5 |
Data[1] Echo Canceler Tail Length (in ms) |
6, 7 |
Data[2] MSB Jitter Buffer Length (in ms) |
8 |
Data[4] Silence Suppression Support (bitmap) 0x00 - No Support |
9 |
Data[5] Fax Relay Supported (bitmap) 0x00 – No Support 0x01 – Support using T.38 |
11 |
Data[6] Modem Relay Supported (bitmap) 0x00 – No Support 0x01 – Support for V.32 0x02 – Support for V.34 |
12 |
Data[7] Digit Relay Support (bitmap) 0x00 – No Support 0x01 – Support using RFC 2833 |
13 |
Data[8] RTP Redundancy Support (bitmap) 0x00 – No Support 0x01 – Support using RFC 2198 |
14 |
Data[9] Number of Coders Supported (n) |
15 |
Vocoder[1] - Payload Type |
16 |
Vocoder[1] - Basic Packet Rate (in ms) |
17 |
Vocoder[1] - Max Packet Rate (multiples of Basic Rate) |
… |
… |
… |
Vocoder[n] - Payload Type |
… |
Vocoder[n] - Basic Packet Rate (in ms) |
14 + n*3 |
Vocoder[n] - Max Packet Rate (multiples of Basic Rate) |
On the VDAC-ONE card, the codecs, G.711, G.726, and G.729 have a basic packet rate of 20 milliseconds. On the IP Network Interface Series 2 card, G.711 and G.726 are 5 milliseconds and G.729 is 10 milliseconds.
IP Network Interface
Series 2 Voice Coder Packet Rate Information
For the IP Network Interface Series 2 card there is a coupling between the Payload Type (codec) and Payload Size (packet rate). Unlike
VDAC-ONE card, the base packet rate (sampling) of a codec is different for different codecs. This implies that a Payload Size, which is defined in multiples of the base packet rate are specific to the Payload Type. The table below shows the relationship between the Payload Type and Payload Size on a IP Network Interface Series 2 card. It also shows a list of all Voice Coders supported by the IP Network Interface Series 2 card.
Table 3-6 IP Network Interface Series 2 Voice Coder Packet Rate Information
TLV Payload Type Data Value (decimal) |
RTP Payload Type |
Basic Packet Rate (ms) |
Default Packet Rate (sampling) (ms) |
Max Packet Rate (ms) |
0 |
G.711 A-Law (64 Kbps) |
5 ms |
4x - 20 ms |
6x - 30 ms |
1 |
G.711 m-Law (64 Kbps) |
5 ms |
4x - 20 ms |
6x - 30 ms |
2 |
G.726 (16 Kbps) |
5 ms |
4x - 20 ms |
9x - 45 ms |
3 |
G.726 (24 Kbps) |
5 ms |
4x - 20 ms |
9x - 45 ms |
4 |
G.726 (32 Kbps) |
5 ms |
4x - 20 ms |
9x - 45 ms |
5 |
G.726 (40 Kbps) |
5 ms |
4x - 20 ms |
9x - 45 ms |
15 |
G.723.1 (5.3 Kbps) |
30 ms |
1x - 30 ms |
4x - 120 ms |
16 |
G.723.1 (6.3 Kbps) |
30 ms |
1x - 30 ms |
4x - 120 ms |
17 |
G.729 (8 Kbps) |
10 ms |
2x - 20 ms |
15x - 150 ms |
IP Network Interface
Series 2 and VDAC-ONE Basic Packet and Maximum Packet Rate Differences
Note that the Basic Packet Rate and the Maximum Packet Rate are different between the IP Network Interface Series 2 and VDAC-ONE cards.
These differences will cause problems with Call Control. The host needs to know which IP Network Interface Series 2 card the Outseize Control and Route Control messages are going to and adjust the packet size accordingly. To compensate for this, the host or upper layer protocol needs to query an IP endpoint’s terminal capabilities. The information returned in the query will provide enough information for a user to build negotiation tables and correctly interface with the IP endpoint.