Release Notes. Version Document #: LTRT-90914

Transcription

1 Mediant 5000, Mediant 8000 and IPmedia 8000 Release Notes Version Document #: LTRT Notice In this document, the Avaya G860 Media Gateway corresponds to the Mediant Note that some features and capabilities contained in this document are not supported by Avaya. Consult your authorized Avaya Sales or Partner resource to confirm the Avaya support features.

2

3 Release Notes Contents Table of Contents 1 Hardware Platforms New Features and Enhancements Management Features IP Networking Features PSTN Features Call Control Features Voice Features Security Features Debugging Features Hardware Features Known Constraints Management Constraints IP Networking Constraints PSTN Constraints Call Control Constraints Voice Constraints High-Availability and Infrastructure Constraints Hardware Constraints...20 Version January 2010

4 Mediant 5000/8000 and IPmedia 8000 Reader s Notes Release Notes 4 Document #: LTRT-90914

5 Release Notes Notices Notice These Release Notes describe the functionality of AudioCodes Carrier Class Media Gateways and Media Servers supported by Software Version 5.8. Information contained in this document is believed to be accurate and reliable at the time of printing. However, due to ongoing product improvements and revisions, AudioCodes cannot guarantee accuracy of printed material after the Date Published nor can it accept responsibility for errors or omissions. Updates to this document and other documents can be viewed by registered customers at AudioCodes Ltd. All rights reserved. This document is subject to change without notice. Date Published: January Trademarks AudioCodes, AC, AudioCoded, Ardito, CTI2, CTI², CTI Squared, HD VoIP, HD VoIP Sounds Better, InTouch, IPmedia, Mediant, MediaPack, NetCoder, Netrake, Nuera, Open Solutions Network, OSN, Stretto, TrunkPack, VMAS, VoicePacketizer, VoIPerfect, VoIPerfectHD, What s Inside Matters, Your Gateway To VoIP and 3GX are trademarks or registered trademarks of AudioCodes Limited. All other products or trademarks are property of their respective owners. WEEE EU Directive Pursuant to the WEEE EU Directive, electronic and electrical waste must not be disposed of with unsorted waste. Please contact your local recycling authority for disposal of this product. Customer Support Customer technical support and service are provided by AudioCodes Distributors, Partners, and Resellers from whom the product was purchased. For Customer support for products purchased directly from AudioCodes, contact support@audiocodes.com. Version January 2010

6 Mediant 5000/8000 and IPmedia 8000 Reader s Notes Release Notes 4 Document #: LTRT-90914

7 Release Notes 1. Hardware Platforms 1 Hardware Platforms The following hardware platforms are supported by Version 5.8 of the AudioCodes high availability Media Gateways and Media Servers software: Mediant 5000 rev 2 with TP-6310 IPM-6310 and TP-8410 Media Gateway boards. Mediant 8000 with TP-6310, IPM-6310 and TP-8410 Media Gateway boards. IPmedia 8000 with IPM-6310 Media Server boards. This release supports the following hardware versions of the SC boards: SC Rev.1 the first-generation SC board based on the SUN CP2300 SBC, running on the SUN Solaris platform the only SC board supported until this release. SC Rev.2 the second-generation SC board based on the Intel CPU and running on the Linux platform. The SC-Rev.2 board is supported starting from this release of the Mediant/IPmedia 8000/5000 software. Note: Consult with an AudioCodes representative on how to order Mediant 8000/5000 systems with an SC-Rev.2 board. On each Mediant 8000/5000 system, the same revision of the SC board should be installed i.e, either an SC Rev.1+ SC Rev.1 pair or an SC-Rev.2 + SC-Rev.2 pair. A mixture of an SC Rev.1+ SC-Rev.2 board is not supported Note: AudioCodes has also recently released the EMS server application on a Linux based platform. Note that the EMS server Solaris and Linux platforms can both manage the Mediant 8000 / 5000 / IPmedia 8000 chassis with either resident SC Rev.1or SC-Rev.2 SC boards. The following hardware versions of the SA-1/RTM boards are supported: SA-1/RTM boards boards without a Timing Module. SA-1/RTM boards with a Timing Module for customers who wish to implement TDM clock synchronization using the BITS Generator or PSTN Line Sync capabilities. Ordering information in reference to these RTMs can be found in the AudioCodes price list. Version January 2010

8 Mediant 5000/8000 and IPmedia 8000 Reader s Notes Release Notes 6 Document #: LTRT-90914

9 Release Notes 2. New Features and Enhancements 2 New Features and Enhancements The following new features have been introduced in the Version 5.8 release of the AudioCodes high availability Media Gateways and Media Servers software. 2.1 Management Features Version 5.8 supports the following new management features: 1. Support of new SC board (SC Rev.2) Hardware revision This version enables the management of the Mediant/IPmedia 5000/8000 chassis using the SC Rev.2 board running on the Linux platform. This version is the first Software release supporting the new SC Rev.2 platform. All Gateway/ Media Server features and functionality available on the SC Rev.1 platform are also available on the SC Rev.2 platform. 2. New installation package format and modified installation process: The Mediant/IPmedia 5000/8000 software uses a new format for the software installation package. The Software installation file has.install suffix and includes the software version number as part of its name (e.g. tg_5.8.62_solaris.install/ tg_5.8.62_linux.install). The Installation procedure was modified as follows: The tg_5.8.x_solaris.install/ tg_5.8.x_linux.install install package should be uploaded to the SC board using the regular CLI user (not root user). The installation is performed via the tg_5.8.x_solaris.install/ tg_5.8.x_linux.install command. Re-configuration of the network or the basic software parameters is performed via the install command. Refer to chapter Installing Mediant 5000 / 8000 Software in the Installation and Operation Manual for more details. 3. New default CLI user s name: The default CLI user's name (created by Mediant 5000 / 8000 software during installation) was modified to the following: username: acladmin password: pass_ Simplified "OS Patches Installation" procedure: The procedure for the installation of the OS patches from the latest Mediant/IPmedia 5000/8000 installation package is now more user-friendly (while preserving the currently installed software version). Support for OS Security Patch Bundle an installation package that includes only OS patch updates has been added. Refer to chapter OS Security Patches (on SC boards) in the Installation and Operation Manual for more details. 5. Improved SNMP performance and better support of standard MIBs: Version 5.8 offers support for the following standard MIBs: ALARM-MIB, ENTITY- MIB, IF-MIB, MIB2, NOTIFICATION-LOG-MIB. The amount of supported real-time PMs that may be simultaneously polled by all SNMP managers has been increased to 100 PMs. Version January 2010

10 Mediant 5000/8000 and IPmedia Graceful opening of TP-6310/TP-8410 boards: When both SC boards are restarted simultaneously, the TP-6310/TP-8410 boards are not reset, unless their configuration was changed via unsupported management interfaces (e.g. WEB). The Media Gateway functionality will not be interrupted in such scenario (calls will be preserved). 7. T3 Alarms Consolidation: This feature enables the filtering of all the Trunks (T1) level alarms in case of a corresponding T3 failure or recovery. This feature is relevant for the T3 PSTN interface only. Alarm consolidation is enabled at the Gateway level and is disabled by default. Release Notes 8 Document #: LTRT-90914

11 Release Notes 2. New Features and Enhancements 2.2 IP Networking Features Version 5.8 supports the following new IP networking features: 1. Support for IPv6 for the Media Subnet: This release of the Mediant 8000/5000 provides support for IPv6 only in Media Subnets. It enables the configuration of IPv6 in the Media Subnet (with an IPv6 Subnet Address and Subnet Prefix Bit Length parameters) and configuration of the IP Network Profile with the IPv6 Default Gateway. 2. New Networking Configuration and Support for Multiple Media subnets: A new networking configuration provides multiple Media subnets - where each Media Gateway board may be connected to a separate Media subnet. In addition, multiple Media VLANs can be assigned to a single Media Gateway board. Up to 8 different Media VLANs can be configured in a system, where either the same Media VLAN can be assigned to all the resident chassis boards or each Media Gateway board in a chassis can have different Media VLANs assigned. Documentation of IP Networking Connectivity was significantly enhanced. Refer to the following chapters in the Installation and Operation Manual for more details: Connecting to the IP Network Examples of IP Network Connectivity Configuration 3. Improved Detection of ES Board Failure: The ES board failure detection mechanism was enhanced to identify failures of individual VLANs on each ES board. 4. Online Provisioning of Static Routes: The configuration of Static Routes for all subnets may be modified online (i.e. while the Media Gateway is unlocked) and without any affect on the Media Gateway s operation. 5. Instant Provisioning of DiffServ Related Parameters: This release enables the instant configuration of DiffServ related parameters in the Media Subnet (not requiring Media Gateway Boards Lock/Unlock- reset). Version January 2010

12 Mediant 5000/8000 and IPmedia PSTN Features Version 5.8 supports the following new PSTN features: 1. Channelized T3: "Channelized T3" configuration allows mapping of OC-3 (SONET) optical interfaces to the T3 links. Up to three T3 links are supported. In contrast to the use of regular T3 coaxial interfaces, "channelized T3" configuration benefits from the APS protection provided by the OC-3 (SONET) optical interfaces. To configure a Channelized T3 configuration, refer to chapter Channelized T3 in the Installation & Operation Manual for more details. 2. Activate/Deactivate Actions on E1/T1 trunks New Activate/Deactivate maintenance actions on E1/T1 trunks allow the temporary stopping/starting of service on a specific trunk by raising/clearing an AIS alarm. These new actions may be useful when Lock/Unlock maintenance actions are not available or require additional configuration (e.g. when an SS7 link is defined on a specific trunk). Refer to chapter Configuring the E1/T1 Trunks in the Installation and Operation Manual for more details. 3. STP Functionality (Alias Point Code) Although the Mediant 8000/5000 normally operates as a SP (Signaling Point) entity in the SS7 network, for some deployments, STP (Signaling Transfer Point) functionality may be required. This version provides this functionality. In order to implement STP functionality, up to two additional alias point codes may be added to the primary point code of the SS7 Node. SS7 messages arriving at the specific Media Gateway board with an alias point code set as their destination will be relayed to the SoftSwitch via the M3UA protocol, similar to the messages destined to the SS7 Node s primary point code. M3UA Routing Contexts may be used to define different routing rules for alias and primary point codes. 4. Improved Online Provisioning of SS7 Subsystem: Improvements in the online configuration of the SS7 subsystem (for M2UA and M3UA architectures). Some dependencies that were enforced by previous Mediant 5000 / 8000 software versions, are no longer enforced. For example: For M2UA - lock/unlock maintenance actions may be performed on both SS7DataLink or UAL Interface objects (administrative state of both objects will always be synchronized). For M3UA the SS7 Data Link may be locked/unlocked when a corresponding SS7 Linkset is unlocked (this essentially allows the addition of the MTP3 link to the operating linkset without any service disruption) Refer to chapters "Configuring the M2UA (SG Side) Application" and "Configuring the MTP3/M3UA Application" in the Installation and Operation Manual for more details. Release Notes 10 Document #: LTRT-90914

13 Release Notes 2. New Features and Enhancements 5. Trunk Channels status in EMS: The Trunk Channels status screen, previously available via the WEB interface on TP boards, is now available via the EMS GUI. The screen may be used to visualize the current E1/T1 trunks usage and signaling channels configuration. Refer to chapter " Viewing Trunk Channels Status" in the Installation and Operation Manual for more details. 6. V.5.2 Access Gateway: This release provides V5.2 Access Gateway functionality. This application implements the LE side of the V5.2 protocol. It aggregates legacy circuit-switched voice from the subscriber side, converts V5.2 protocol messages to H.248 IP protocol and then forwards them to a soft switch and vice versa. The gateway and the softswitch may be used as a replacement for the traditional Class 5 PSTN switch. The V5.2 Access Gateway application implemented on the Mediant 8000/5000 has the following capabilities: Support for E1 trunks on TP-8410 Media Gateway boards only. Support for the Mediant 8000/5000 redundancy mechanism (warm redundancy for Media Gateway boards is currently supported). V5.2 Links: each TP-8410 board includes 42 E1 trunks that may be configured as V5.2 links or as E1 transparent trunks (without voice e.g. for PSTN clock synchronization). V5.2 Interfaces: the E1 trunks, configured as V5.2 links, are divided into groups or V5.2 interfaces each with between 2-16 E1 trunks. Up to 31 V5.2 interfaces are supported. Signaling Channels: the V5.2 interface uses 2 timeslots for signaling (active and standby) in separate V5.2 links called Primary and Secondary links (Protection Group). In both signaling links, timeslot 16 is dedicated to the V5.2 signaling. Under normal circumstances, a V5.2 interface starts up with the signaling on the Primary link. Voice Channels: in all V5.2 links, timeslots 1 to 31 (except for timeslot 16-- signaling links) are used as voice channels. User Ports: each TP-8410 board supports up to 10,000 PSTN user ports distributed across the V5.2 interfaces; the number of user ports per V5.2 interface is determined by the following formula: 300 * "Number of Trunks" e.g. if the V5.2 interface has 16 trunks up to 4800 user ports may be defined on it. Several provisioning and maintenance features were introduced for the V.5.2 Access Gateway application in this release. Refer to the IOM manual for a detailed description and provisioning instructions. Version January 2010

14 Mediant 5000/8000 and IPmedia Call Control Features Version 5.8 supports the following new call control features: 1. IP-to-IP functionality in MEGACO: This release officially supports IP-to-IP (IBGF) functionality in Media 8000/5000 systems. As a consequence, the user can now configure more than one Media VLAN per single Media Gateway board and use different Media VLANs across resident chassis boards. 2. SIP IP-to-IP functionality B2BUA features: This version supports the SIP IP-to-IP and SIP B2BUA functionality. Using this feature, the IP2IP SIP session can be applied independently for each call leg using global gateway parameters, such as coders, or by using IP Profiles associated with each call leg. Different IP Profiles can optionally be configured in IP2TEL/Inbound and TEL2IP/outbound tables to provide different configuration for the two IP2IP call legs. As part of this feature, IP Groups functionality is provided for IP-to-IP routing. To support this new functionality, new provisioning tables were added IP Group Table, Proxy set table and Accounting Table. In addition, several new extensions for existing SIP related provisioning tables were provided. Refer to the IOM manual for provisioning instructions and a detailed description. Note: In order to use these functionalities in the Media Gateway system, customers should consult their AudioCodes representative to purchase the relevant special license for enabling this feature. 3. TDM Hairpinning for MEGACO: This release supports the provisioning of TDM hairpinning functionality in MEGACO. TDM Hairpinning is a scenario where a call is made between two TDM endpoints (channels) on a single Media Gateway board. In this mode, the inbound media passes via one TDM channel and the outbound media passes via another TDM channel through the use of an internal PCM loop on the Media Gateway board. Release Notes 12 Document #: LTRT-90914

15 Release Notes 2. New Features and Enhancements 2.5 Voice Features Version 5.8 supports the following new voice features: 1. Change in default value of Modem Transport Type: Default values of the V21 Modem Transport Type, V22 Modem Transport Type, V23 Modem Transport Type, V32 Modem Transport Type and V34 Modem Transport Type parameters have been changed to Bypass (to prevent unnecessary DSP resources allocation). 2. Support for RTP Sync and RTP Async Mediation Transcoding modes: The following Mediation Transcoding Modes are supported in Version 5.8: Smart Transcoding (default) transcoding is selected according to the channels configuration. If two WB coders excluding FAX are configured, RTP Sync will be selected. Otherwise TDM Transcoding will be selected. TDM Transcoding packets are sent via channel activation per internal (TDM) clock. RTP Sync Transcoding packets are sent via RTP channels activation (Sync mode) for IP to IP transcoding calls. RTP Async Transcoding packets are sent only upon receipt of the packet from the network for IP to IP transcoding calls. 3. Support for LBR to/from HBR codec transcoding: When Megaco Resources Optimization is enabled, the LBR to/from HBR codec transcoding is performed as follows: One DSP is allocated on voice calls IP to IP transcoding, where at least 1 termination is G.711 with ptime = 20 with no added features (i.e no no-op, no RTP redundancy, fax transparent, DTMF transparent) and the 2nd termination may be any other coder (including G711) with fax transparent and DTMF transparent. No DSP will be allocated when all terminations use: The same coder The same payload type (according to the channel stream mode, i.e if the first channel stream is receive-only or send-receive and the other channel stream mode is send-only or send-receive. In this case, the first channel RX payload type must be equal to the second channel TX payload type, and vice versa), The same no-op payload type The same fax transport type (and payload type if it is relay), the same DTMF transport type (and payload type if it is relay) and the same ptime value. Two DSPs will be allocated in all other cases. 4. Support for new DSP templates: The following DSP Templates are supported in v5.8: G.723 (0), AMR (1), EVRC (2), ilbc (3), AMRWB (4), EVRCB (5), G.729EV-12 (6), EG.711/iLBC (7), G.729EV-32 (8). The following mix of DSP templates is supported in v5.8: AMR (1) + EVRC (2); AMR (1) + EVRCB (5); AMR (1) + EG.711/iLBC (7). Version January 2010

16 Mediant 5000/8000 and IPmedia Security Features Version 5.8 supports the following new security features: 1. Guidelines for Securing the Mediant 5000/8000: A new section Security Configuration Guidelines in the Installation and Operation Manual provides precise step-by-step instructions for configuring security features on the Mediant 5000/8000 to establish a secure configuration. 2. Password-less Access to the Command Line Interface (via SSH): Password-less access to the CLI interface is supported, based on the RSA or DSA public/private key usage. Refer to chapter Password-less Access to the CLI Interface in Installation and Operation Manual for more details. 3. Latest OS Security Patches for SC boards: The Version 5.8 release includes the latest OS security patches for the SC boards, updated on April 22, Debugging Features Version 5.8 supports the following new debugging feature: The ES board s port mirroring configuration is preserved when ES port mirroring is enabled/disabled. 2.8 Hardware Features Version 5.8 supports the following new hardware features: 1. Support for a new Hardware revision of the SC board (SC Rev.2): A new second-generation SC board using an Intel CPU and running on the Linux platform is now provided. 2. Support for the PEM status indication for the Mediant / IPmedia 8000 according to the following rules: The PEM module is color-coded Green in the EMS GUI when it operates correctly. The PEM module is color-coded Red in the EMS GUI in the following cases: PEM hardware failure (detected as lack of I2C communication with corresponding SC boards) Power Input is not detected. Reverse polarity on Power Input is detected. If the chassis contains an old version of the PEM module which doesn t support this feature, the PEM module is color-coded grey. Release Notes 14 Document #: LTRT-90914

17 Release Notes 3. Known Constraints 3 Known Constraints This section lists the known limitations of Version 5.8 of the carrier class Mediant Media Gateways and IPmedia servers. 3.1 Management Constraints This version includes the following management constraints: 1. For TP-6310 based systems equipped with the Timing Module and using the Standalone clock mode: alarms related to the Timing Module are rarely displayed. The user should disregard these alarms unless they have the critical status. In addition, the Timing Module is displayed as red in the EMS. 2. Constraints in the rollback procedure of the Online Software upgrade: If abort is performed during the VoP boards upgrade phase, some VoP boards may remain locked after the rollback or reset without a Graceful Shutdown period. It is not recommended to perform abort during this phase. ES boards may be reset during the rollback operation, even when this is not necessary. 3. The Online change of the Voice Prompt (VPF) file is supported only when the file size is smaller than the amount of the available free memory on the IPM-6310 board (calculated as the total amount of memory, less the size of the currently loaded VPF file). Larger files should be configured while the IPM-6310 board is locked. 4. Provisioning of a SIP Tel to IP routing table. Although the paremeter DestIPAddress is marked as instant, setting / changing its value requires the Lock/Unlock of the corresponding table s row. Also note that board reset is required. 5. The following History PMs are not supported in this release: SS7LinkInService %, SS7LinkOutofService %, SS7LinkSet SN0 Out Of Service %, SS7LinkSet SN1 Out Of Service %. 3.2 IP Networking Constraints This version includes the following IP networking constraints: 1. The UDP checksum for media packets will not be applied to the CALEA and the IP2IP connections without transcoding the client s UDP packets 2. Debug Recording (per TP board): Only one IP target is allowed. No more than 50 trace rules are allowed at any one time. No more than 5 media stream recordings are allowed at any one time. 3. Debug Recording. When the user creates a debug recording rule of type Channel ID, up to 60 channels can be traced. When the user creates a debug recording rule to trace more than 60 channels, an EMS warning is generated for the user; however the rule is created and the unlock action succeeds. This rule cannot be later removed via the EMS. Therefore, users should not define more than 60 channels.in the debug recording rule. 4. In SC Rev.2 Linux-based systems, the user should not apply ES mirror filtering. Version January 2010

18 Mediant 5000/8000 and IPmedia PSTN Constraints This version includes the following PSTN constraints: 1. All trunks on a single board should belong to the same Trunk Type (either E1 or T1). 2. In STM1 and OC3 configurations, path alarms do not show the real state if the higher level is not synchronized. For example, if there is no LOS on both PSTN Port A and Port B, the path level will display "No Alarm". 3. When the DS3 interface is not connected, a trunk under this DS3 interface is displayed as either an LOF or an AIS alarm. 4. ISDN NSF IE Constraints: The software does not support the receipt of the NSF IE. The software supports sending of only one NSF IE in a Q.931 message. The software does not support a mixture of the NSF IE with other supplementary services. In general, three components are supported in a Facility message. In case the NSF IE is included in the message, only one component is supported. 5. When using the E1EuroIsdn ( Protocol Type ( Trunk Parameters Provisioning in EMS), Supplementary Services - AOC (Advice Of Charge) and SS_ETSI_AOCD_CHARGING_UNIT, the following may occur: When the invoke_type field has the value of SS_AOCD_SPECIFIC_CHARGING_UNIT, the num_of_recorded_units field is sent with an incorrect value. 6. When using E1EuroIsdn (enum 1) Protocol Type ( Trunk Parameters Provisioning in EMS) and the board receives a Q.931 information message, the KeypadSize field in the acev_isdn_q931_information_message event may be set with an incorrect value. 7. SDH TU-11 Byte Synchronous mapping is not supported. 8. For TP-6310 SDH/SONET and DS3 interfaces: if a trunk was in an LOF alarm state, after the alarm ended, the trunk tends to revert to an RAI alarm state for a short period of time before moving to no alarm (clear) state. 9. SS7: Online configuration of the UAL Group is not supported if the corresponding SCTP port has active associations established on it. 10. The Redundant MTP3 Group (shared point code) configuration may include only two TP boards. 11. Only one SS7 Node is supported per MTP3 Group. 12. The NFAS Interface ID parameter ( ISDN/DPNSS tab in the Trunk provisioning frame in EMS) is not used for IUA. It is only used for the NFAS ISDN application. 13. The Q931 Relay Mode parameter ( PSTN tab in EMS) is not needed for IUA. 14. Sigtran implementation constraints: Only SIGTRAN Override Mode is supported. SIGTRAN: The Textual Interface Identifier is not supported. 15. The T3 channelized configuration does not work properly when the OC3/STM1 carrier is configured APS protected. Release Notes 16 Document #: LTRT-90914

19 Release Notes 3. Known Constraints 3.4 Call Control Constraints This version includes the following call control constraints: 1. MGCP and MEGACO control protocols are not supported on the same TP board. 2. According to the H248.9 sub-series, the PST and PRT parameter values can be any positive value. In IPmedia systems, the value should be configured to a value greater than The maximum MKI length in an SRTP packet is 4 bytes. 4. The combination of the "UNAUTHENTICATED_SRTP" SRTP session parameter with either "UNENCRYPTED_SRTP" and/or "UNENCRYPTED_SRTCP" is not supported msec RTP frames using the EG.711 coder are not supported. 6. For TP-6310 based systems with MGCP/TGCP call control: when modifying a channel to T.38, the voice statistics are not saved and zero values will be returned if they are requested. 7. MGCP BAU/AAU packages are not supported. 8. For the MEGACO Call Control protocol: when the FAX is set to transparent mode and FAX events are requested, the call must be closed and opened if the FAX ended while in this mode and no change to T.38 or Bypass occurred. 9. For the MEGACO Call Control protocol: when sending an empty eventbuffer descriptor, the current collected events are not erased. 10. For the MEGACO Call Control protocol: when creating a BCT context, there is no legality check on the topology i.e a case in which one termination has two inputs, is not handled. Therefore, it might result with a one-way voice. 11. The MEGACO command descriptors - ModemDescriptor and MuxDescriptor - are not supported in this version. 12. For the MEGACO Call Control protocol: the auditcapabilities reply does not return all parameter values. 13. Size Limitations (for the MEGACO Call Control protocol): Maximum contexts in reply to auditvalue of ALL contexts and Root termination = 2000 Maximum command length = bytes Maximum number of transactions per message = 10 Maximum number of actions per transaction = 150 Maximum number of command requests per action = 10 Maximum number of command replies per action = 100 Maximum number of signals in a signal descriptor = 2 Maximum number of signals in a signal list descriptor = 30 Maximum number of reported signals = 50 Maximum number of events in an event descriptor = 16 Maximum number of reported events = 50 Maximum number of observed events = 10 Maximum number of event parameters = 5 Maximum number of audit return parameters = 100 Maximum number of DigitMap alternatives = 32 Maximum length of DigitMap = 150 Maximum dial string length = 30 Maximum length of DigitMap name = 30 Version January 2010

20 Mediant 5000/8000 and IPmedia For the MEGACO Call Control protocol: the max number of the terminations in a BCT/IP-to-IP context is limited to For the MEGACO Call Control protocol: BCT (Bearer Channel Tandem) - used by law enforcement agencies - and PoC (Push to talk Over Cellular) are supported for up to 30 listeners. 16. For the MEGACO Call Control protocol: the maximum number of terminations in a Conference context is limited to For the MEGACO Call Control protocol: when performing an RTP-RTP call with one termination in the HBR coder and the other in the LBR coder, and the parameter Megaco Resources Optimization ( Call Control tab in Board provisioning EMS frame) is enabled, the RTP termination with the HBR coder can only be used for voice. No detectors and generators are enabled. 18. For the MEGACO Call Control protocol: the Move command is not supported on the RTP termination in the IP-to-IP context. 19. For the MEGACO Call Control protocol: on a DSP template mix configuration of AMR and EVRC, the user cannot modify an Endpoint from AMR to EVRC and vice versa if the Endpoint is part of a conference call. 20. For the MEGACO Call Control protocol: hierarchical wildcard termination naming like rtp/*, is not supported in the TOPOLOGY descriptor. Full wildcard (*) is supported. Release Notes 18 Document #: LTRT-90914

21 Release Notes 3. Known Constraints 3.5 Voice Constraints This version includes the following voice constraints: 1. When setting the configuration parameter Megaco Resources Optimization (EMS Board s parameters provisioning frame, tab Call Control to Enable (1), the following constraints exist on IP to IP calls: No fax/modem manipulations - i.e. no Bypass or T.38 Relay or events detection support. On the HBR (e.g. G.711) leg of the IP to IP call: No Generation/detection of any signal (e.g. DTMF). ptime must be set to the default value (20 msec). No support for RFC 2833/ When performing an IP to IP call with a wideband coder on each leg, if the Fax / Modem transport type for one of the legs is not transparent, the interconnection made will not preserve the Wideband (WB) quality of the call and therefore uses a Narrow Band (NB) interconnection instead. 3. Streaming cannot be performed on IP to IP WB calls. 4. Playing Wideband announcements to the TDM side causes bad voice. 5. NTT Caller ID Type 2 constraints: The NTT standard describes the Caller ID Type 2 generation as a sequence of an incoming-call signal, "C" and "D" DTMFs and FSK modulated data. The Generation of the incoming call signal remains the responsibility of the application, however, "C", "D" and the FSK data are generated by the supplied service. The signal can be generated using the UDT signal generation mechanism. Prior to the detection of NTT Caller ID Type 2, there are two DTMF ("C" and "D") detections which remain unscreened. 6. Setting the V.21 Modem Transport Type ( Fax/Modem tab in EMS) to Bypass and Fax Transport Type to Relay, results in entering the Fax Relay mode at the 2100 Hz signal. Only at the end of this signal, does the channel enter Bypass mode. RFC 2198 redundancy mode with RFC 2833 is not supported (i.e., if a complete DTMF digit was lost, it is not reconstructed). The current RFC 2833 implementation does support redundancy for lost inter-digit information. 7. A channel should not be re-opened during IBS detection. Such an action could cause the detector to send multiple events on the same IBS input. 8. The duration resolution of the On and Off time digits when dialing to the network using RFC 2833 relay is dependent on the basic frame size of the coder being used. 9. Incoming CNG T.38 packets do not switch the channel to T.38 mode. 10. When the fax CNG detector is not Transparent, a fax CNG tone received from the TDM cannot be detected using the Call Progress Tone detector. 11. Playback with duration set to less than 80 msec is not supported. 12. EVRC Interleaving, according to RFC 3558, is supported only on the reception side. 13. If a voice prompt is used before a silence period in a Voice Prompt Sequence, the end of the voice prompt will be cut off by up to 80 msec. To avoid this situation, the user should add a silence period of 80 msec to the end of the specific voice prompt. 14. It is not possible to play a Narrow Band G.711 file on an IP to IP HD transcoding session (e.g. WB AMR vs. G.722). Version January 2010

22 Mediant 5000/8000 and IPmedia HTTP and NFS Streaming Constraints: The number of supported Wideband NFS streaming channels is up to 630. Only G.711 A-Law and μ-law coders are supported for the.au files. Streaming is currently not supported on mediation channels. 3.6 High-Availability and Infrastructure Constraints This version includes the following HA and infrastructure constraint: TP-6310 based systems configured for IPSec for control protocol transport, may experience a large bulk of Syslog error messages during the TP switch-over. 3.7 Hardware Constraints This version includes the following hardware constraints: 1. This version does not support a mixture of TP-6310 and TP-8410 Hardware platforms in the same chassis using the Multiple Redundancy groups feature. 2. This version does not support the TP-1610 platform. TP-1610 HW platform users should not upgrade their system to Version This version supports up to 6+1 boards for SIP based Mediant 8000 systems. 4. The only combination of different Hardware platforms supported in the same chassis using the Multipe Redundancy groups feature in this release is OC3/STM1 and T3 based TP boards. 5. The Mediant 8000 product supports up to 5+1 boards for TP-8410 based systems. Release Notes 20 Document #: LTRT-90914

23 Release Notes 3. Known Constraints Reader s Notes Version January 2010

24 Mediant 5000, Mediant 8000 and IPmedia 8000 Release Notes Version