This document lists all software fixes for VoIP MultiPath Switch/Gateway and Call Relay Products running maintenance software P108-09-23 and previous.
These maintenance release notes apply to the following products:
A software maintenance release is a release of software that has been created by Quintum to resolve an inconsistency or "bug" that has been identified within a release.
Maintenance releases (for Second Generation Tenors) can be identified by the 3rd set of digits in the release name as PX-Y-Z, where the Z is the maintenance number. All maintenance releases will be built on top of the latest GA release of software. For example, if P102-11-00 is the latest GA software, the first maintenance release of software will be P102-11-01. The notes below are cumulative since the last Generally Available (GA) software release P108-09-00. Maintenance software goes through limited testing from NET, but has been verified as resolved by the customer who identified the problem.
If additional maintenance releases are required for a specific GA release, each new maintenance will contain all previous maintenance fixes. For example, maintenance release P106-11-02 will include all maintenance release changes from P106-11-01.
On a scheduled basis, NET will release a full GA version that will include all previous maintenance released that have undergone full system test.
CMS COMPATABILITY NOTE: P101 and LATER CODE ON CMS ONLY SUPPORTS SERIES 2 CONTROLLER AND PERIPHERAL CARDS.
If EnableLocalRouting was set to 1, DNCM routing took precedence over the Routing Table. However, after a power cycle the local routing did not work. This has been resolved.
The Autoswitch feature has been disabled, even if a valid AutoSwitch license is discovered.
When a call was made from the PTSN to Tenor to Lync and then the call was put on hold from the Lync side with a re-INVITE SDP from Lync Mediation contained a=sendonly, the PSTN caller could not hear the music on hold played from the Lync Server. This has been resolved.
For security reasons, Port 17185 will not be opened.
After an IP-IP call was up through the Tenor, the server was sending the Tenor a re-Invite with no SDP. The Tenor took this re-Invite as a trigger to send a hold request to the far end. Instead, a regular re-Invite (with SDP) should have been sent to the far end, which would result in an OK with SDP to the server and a received ACK with SDP from the server. This has been resolved.
Note: A varconfig implemented this feature in P108-09-14 ("DtmfCidStartDelimiter” and “DtmfCidEndDelimiter”) but are now removed and replaced with the below configuration options available in the Command Line Interface (CLI).
Denmark Caller ID generation and detection is now included as a feature. There are two new configuration fields available for Caller ID generation and detection: DtmfCidStartDigit and DtmfCidEndDigit. These fields are available via Command Line Interface (CLI) under Gateway.
DtmfCidStartDigit. Valid entry: 0 - 15. Default entry: 13
DtmfCidEndDigit. Valid entry: 0 - 15. Default entry: 12
Entry definitions include the following:
0-9: Digit '0'-'9'
10: Digit 'A'
11: Digit 'B'
12: Digit 'C'
13: Digit 'D'
14: Digit '*'
15: Digit '#'
Guidelines
The Tenor DX Series Digital and Analog VoIP MultiPath Switches has been qualified for Direct SIP Enhanced Gateway in support of Microsoft® Lync™ Server 2010 deployments.
A new varconfig file is available to support this feature:
lyncInterOp 1. This enables Tenor to drop short packets (i.e., STUN and Comfort Noise).
lyncInterOp 0. This disables Tenor from dropping short packets (i.e., STUN and Comfort Noise).
Guidelines
Using an IVR prompt when a Multipath call is routed to the PSTN is now supported in MultiPath routing. This has been fixed to support MultiPath routing.
The Tenor did not send a PRACK message on a SIP 182 message from an IP-PBX, which caused the PBX to not open the audio path for the queued call. The Tenor will now respond back with a PRACK message.
When a call was put on hold from a Lync client, the caller did not hear the music on hold coming into the Tenor from Lync. This has been resolved.
When a message was sent to SSG having Request-URI as INVITE, the message was not completely sent through. This has been resolved.
A digit was missing for the DNIS number (from the To header or Request URI). This has been resolved.
NOTE:: For upgrades to P108-09-21: When using the New Routing Table and direct DNCM routing, ensure EnableLocalRouting is configured to 1 (enabled). If this field is not configured properly, the existing direct DNCM routing will not work.
With Multipath routing, if the dialed number matched a DNCM, the Tenor would directly route the call between the analog ports, and not use the Routing Table. A new feature enables the Tenor to use the Routing Table to send the call to a SIP server, and have the call routed back to the Tenor, instead of doing Direct local routing.
A new configuration item, EnableLocalRouting (available via Command Line Interface (CLI) under Gateway.) can be configured to enable/disable this option. Valid entries: 0: Default, disabled (the Tenor by default will use the Routing Table instead of direct DNCM Routing) or 1: Enabled (direct DNCM routing is used).
When a NAT IP directory was configured, the Tenor sent out the external NAT IP address (configured under the Ethernet setting) as NAT in the SIP invite and in the SDP to the IP side, rather than sending out its own locally configured Ethernet IP address. This has been resolved.
When a Lync client (A) was forwarded with a Ring No Answer to another Lync Client (B) within the Lync environment, the caller heard a partial ring before silence (even though the Lync Client B was still ringing until it went to voice mail). This has been resolved.
When a Tenor received an Invite with SDP parameters, the forwarded invite from the Tenor was properly encoded. However, if the incoming parameters were not in irder, the forwarded invite from the Tenor was incorrect. This has been resolved.
When the Tenor (using the New Routing Table) received a SIP invite with any of the configured phone numbers in the DN-Channel map table, the Tenor rang the first available FXS channel (like a hunt group) rather than ringing the specific FXS channel based on the phone number that is in the DN-Channel map table. This has been resolved.
If a Tenor had both FXO and FXS lines configured for offline operation nd the CallerID detection type configured in CAS (set to Type 7), a call into the Tenor would cause a reboot. This has been resolved.
With Session Timer supported in the Tenor, when a SIP End Point sent an Invite indicating that it wanted to be the refresher (refresher=uac), the Tenor was overriding with refresher=uas in its response, instead of honoring the client’s request to be the refresher. This has been resolved.
When the Tenor BX received a Call Progress, it would not send the 180 Ring or 183 SIP message to the Lync/ Mediation Server. As result, the Tenor would receive a SIP CANCEL message from the Lync/Mediation Server. This has been resolved.
No changes.
When the st ds1 command was issued, the Tenor reboot. This has been resolved.
When the primary proxy was down, the INVITE messages were send to the secondary proxy, but subsequent messages (i.e., PRACK and BYE) were being sent to the secondary proxy. This has been resolved.
When the Tenor sent out an INVITE message, if the proxy authentication credentials failed, the Tenor would keep adding multiple authentication headers by repeating them (even if the credentials were passed). As a result, this eventually caused the message to grow too large and end the calls.
The Tenor was not decoding the SIP header message correctly. This has been resolved.
When the Tenor sent an invite (without an SDP) to an endpoint. and the endpoint sent back the 200 OK message, an exception occurred and the call failed. This has been resolved.
Tenor was unable to decode the header in the Refer message. This has been resolved.
No changes.
When a Tenor attempted to retrieve a parked call, the call was dropped. This has been resolved.
When a call transfer was attempted with early media turned on, the Tenor reset.
This has been resolved.
There was a problem with one way audio and the Called party could not hear the caller. This has been resolved.
Note: This feature is now available for CLI configuration, rather than var_config. See P108-09-21.
The Tenor reset about every two hours with the following PRI>SIP call flow:
This has been resolved.
Tenor had an issue with a re-Invite with no SDP after a call was put on hold, and resulted in one way voice after transfer. This has been resolved.
After an initial call was setup, and a transfer was initiated, there was an issue with a second invite and the call failed. This has been resolved.
An attended call transfer to a User Agent in the same Tenor resulted in one-way voice from the Tenor to the far end. This has been resolved.
A new command in the var_config.cfg file, mapCauseCode47To34FromSipToCircuit, will now map cause code 47 to 34, and send out 34 back to the calling PRI side. Options to enable/disable this option are as follows:
mapCauseCode47To34FromSipToCircuit 1. Enabled. Cause code 47 will be sent out as 34 back to the calling PRI side.
mapCauseCode47To34FromSipToCircuit 0. Disabled. When Cause code 47 is generated from SIP to ISDN, it will be sent out as 47.
A new varconfig sipDoNotEscapeDigitsInPhoneNumbers has been introduced to allow the *, # characters to be escaped. When the varconfig command is used, these characters are not escaped and sent out literally in the Invite Header and To field.
The Tenor reboot automatically when multiple NT tables were used. This has
been resolved.
If a '#" sign was located at the end of a destination number, it caused the origination Tenor to crash. This has been resolved.
A specific "From" header (in which the From line ends with "cscf")
was not being properly decoded. As result, when the Tenor received the Invite,
it was rejected because of the decode problem, and the call was dropped. This
has been resolved.
When MultiPath routing was used, not all the fields in CDR format 199 were set to proper values. This has been resolved.
A new ARP (Address Resolution Protocol) expiration varconfig command, arpexpiration, is now configurable in the Tenor to determine how long (in seconds) an ARP table entry should live. Valid entry: 1 - 1200 seconds. Default entry: 1200 seconds (20 minutes).
In CLI, there was a problem with help not being displayed for the RoutingTable or NumberTable. This has been resolved.
For Tenor Digital Units (Tenor DX and Tenor BX), the attributes of PowerOffBypass and PhantomPowerPassthru (available under Slot-2) were not able to be configured via the auto provisioning feature. This has been resolved.
The ANI TON/NPI was being reported incorrectly in the Event Log due to an internal decoding error. This has been resolved.
AOPC (Allow Only Proxy Calls) was not working when using DNS for registration purposes. This has been resolved.
Auto Provisioning was not functional when upgrading from a previous release to P108. This has been resolved.
Two new enhancements have been implemented in the Tenor: Host Name and Dial Plan
Host Name. In the Tenor, you are now able to configure a Host Name for the Tenor. If the Host Name is configured and the value in SIPSG indicates to send the IP address in the From Header, the host name will now be sent instead. Through the var_config.cfg file, you are able to configure the Host Name: TenorHostName <hostname>.
Dial Plan. A new dial plan option (Supplementary Services 3) is now supported in the Tenor. Access this feature in the Tenor Configuration Manager as follows:
For IP-IP calls, when a call was put on hold, the hold re-Invite was not being passed through correctly. As a result, MOH (Music on Hold) was not being played. This has been resolved.
The Tenor gateway was receiving a SIP invite from the IP-PBX, but failing to
decode the “Record-Route” field in the invite. Now, the Invite decodes
properly and will include the correct Record-Route field.
The Tenor (New Routing IP-IP calls) altered the outgoing Invite as though the
request was from the PSTN, rather than another IP. The Tenor now passes the
From and Contact fields without altering these fields.
Tenor should go into safe mode if it reset numerous times in a specific amount of time. However, on one occasion, the Tenor reboot into safe mode upon initial startup. This has been resolved.
For a Tenor registration with Authorization parameters, the user name in To/From was the same as the user name in the Authorization header. These needed to be different. This has been resolved.
If Table based routing was enabled, the Called number was
missing from the CDR record. This has been resolved.
When any changes were made to the map.cfg file, the Tenor would require a reset. To resolve this, a new command, cmd sip readmap, allows the Tenor to read the values of the map.cfg file without requiring a reset.
When both source and destination Tenors were registered to a SIP server (in the SIPSG of the destination Tenor, the IPRG was configured to 'not set'), and a call was placed from the source Tenor to the destination Tenor, the destination Tenor reset as soon as it received the Invite. This has been resolved.
When an Analog phone answered a call, and the call was put on/off hold, if the far end disconnected the call, the Analog phone would not hear the disconnect tone. This has been resolved.
A SDP decode error appeared in the Tenor. This has been resolved.
On a re-Invite, when the IP address in SDP changed, the Tenor put the correct IP address in the IP header, but the Ethernet header still contained the MAC address of the previous audio destination. This has been resolved.
When a call failed, the Tenor was not handling the call failover properly. This had to do with a DNS Host Timer refresh issue, but it has been resolved.
The command, IncomingDNISinTo (previously a varconfig option named SIPUseToAsNumber, now available under SISG in the Tenor Configuration Manager and CLI) is now used as follows:
For the CLI
Access SIPSG. The two fields are as follows: IncomingDNISinTo 0 (Incoming DNIS is taken from Request URI) and IncomingDNISinTo 1 (Incoming DNIS taken from the To: header).
For the Tenor Configuration Manager
Click on SIPSG > Advanced. From the Incoming DNIS In drop down box, select Request URI (Incoming DNIS is taken from Request (URI) or Header (Incoming DNIS taken from the To: header).
A new varconfig parameter QSIGProtocolProfile is now available, which allows you to change the Q.SIG protocol profile to either ISO variant or ECMA variant. Valid entries are as follows:
QSIGProtocolProfile 0. ISO variant (default value).
QSIGProtocolProfile 1. ECMA variant.
In AutoProvisioning, following a post-provisioning reboot, the Tenor would not wait the proper amount of time before attempting to download the provisioning file. As a result, the Tenor would continually reboot itself.
In AutoProvisioning, when the Tenor was set to Linetype 0 ( Digital Interface-1), it was not taking effect. This has been resolved.
The ARP expiration time has been made configurable per a new varconfig command arpexpiration. Through this command, you can configure how long (in seconds) an ARP table entry should live. Valid entries are 1 - 1200 seconds; default value is 20 minutes (1200 seconds). For example, arpexpiration 160 will allow the ARP table entry to live for 160 seconds.
When a call was up and the CallRelay received a re-invite, it sent an OK with an OFFER. The far ends responded with an ANSWER, but the media was different than the media from the original call. As a result, the CallRelay was unable to resolve this. This has been resolved.
Note: Applies to New Routing or CRSP IP-IP calls only.
The Tenor dropped the Diversion header on the outbound IP call leg. This has been resolved.
When a caller blocked his/her Caller ID from being displayed on the calling party’s phone, the PSTN transmitted just the letter P as the Caller ID. The Tenor added this letter P in the FROM field of the SIP INVITE, which was displayed as the Caller ID on the receiving SIP endpoint. This has been resolved.
When a call was up and the far end sent the Tenor a re-Invite with T38 fax, the Tenor was not configured for T.38 and sent a 415 (unsupported media type) in response. AT&T testing required a 488 to be sent instead. This has been resolved.
The following Diversion header was not decoded properly:
"Diversion:"AA1 HostedPBXGroup1"<sip:13359013@atyaf.com;user=phone>;privacy=off;reason=deflection;answered;counter=1".
This has been resolved.
When a call was connected and the far end sent a re-Invite (which the Tenor matched on session), the Tenor failed to match the request-uri and declared that there was a forking situation.The Tenor should not have been checking for forking when the call was already established. This has been resolved.
If the incoming SIP Invite header did not contain a Category header, the Tenor would incorrectly pass a 255 in the Category IE. Instead, when there was no Category in the Invite, the Category should have been set to the Calling Party Category configured in the ISDNSG. This has been resolved.
When there were two routes defined from an incoming SIP call, and no circuits
were available, the second route was never being attempted. This has been resolved.
When the Tenor received an Invite, it failed to decode the TO header. As a result, the call failed and an exception was generated. This has been resolved.
When using the varconfig command cidt2 1 (supports the '.' placeholder), the Tenor failed to translate Caller ID for inbound calls on the IPRG with an associated CID translation directory that included a number pattern and replacement number containing '.' in it. This has been resolved.
While downloading the cli_help_msg.txt file to a Tenor, the file may have gotten corrupted due to ftp/network problems. This has been resolved.
In TCRG, when the ivrtype is set at 1 or 8, the following fields are now available:
When an IPRG was attached to a SIPSG (for inbound SIP calls), if there was a static route match based on destination address, the IPRG in the static route did not take effect. This has been resolved.
When a called ID translation was used with positional dots in the Pattern, and a non-matching pattern came in, the translation would still match and then send an invalid caller ID. As a result, a SIP error would occur, resulting in the Contact and From fields missing. To resolve this issue, enter cidt2 1 in the var_config.cfg file.
When the Tenor received a SIP invite, the Tenor could not decode the URI in the Referred-By header. This has been resolved.
The IP address in the SDP was being sent by the Tenor as private, even when the external NAT was set. The IP address should have been sent as public. This has been resolved.
In dual registration Proxy failover mode, the Primary Proxy should have attempted proxy fail over mode first, and if that failed, the secondary Proxy should have been attempted. Instead, the Tenor did not failover to the secondary SIP server on a no response from the Primary Proxy. As a result, all subsequent calls failed. This has been resolved.
With FXO ports configured as IVR type 1 (second dial tone), when the user called in and received second dial tone, and then dialed an extension that was configured as a specific channel DNCM, the call was not routed according to the DNCM parameters. This has been resolved.
For SS7, when calls were sent to the Tenor for a loopback test on a previous circuit, the Tenor would ignore the call. Now, the Tenor waits for the results of the loop back test to continue or drops the call.
Ringback was not working with IVR and early media enabled in SIPSG. This has been resolved.
Tenor failed to decode SipInfo payload when 11(*) and 12 (#) were in the payload of the SipInfo received from a ResponsePoint unit. The Response Point unit encoded these characters differently depending on the brand of the phone from which the call originated. For example, if the call originated from a Syspine phone, characters * and # were in the payload. If the call originated from an Astra phone, numbers 11 and 12 were in the payload. Tenor could only decode characters * and # and not numbers 11(*) and 12(#). This has been resolved.
When the Tenor received a final response to an ongoing Invite, it re-sent a Cancel message, which made the call fail. Now, the Tenor will send a BYE.
The config parameter, AllowOnlyProxyCalls, in SIPSG
did not work for TCP calls. This has been resolved.
Cname was not being encoded properly for outgoing PRI calls when NI2 was used. This has been resolved.
The names for two backup commands have been changed (these are general commands available under configuration in CLI):
try restore database changed to restore database
try backup database changed to backup database
When a Tenor received an Invite with the Diversion header field, the Tenor was unable to decode the Diversion header with a Tel URI, and the Invite was not processed. This has been resolved.
Tenor routed calls based on the P-Called-Party-ID header as the called number. Now, the Tenor will route the calls based on the "To" header.
In New Routing, a Number Table match was found even if the normalized number was longer or shorter than the configured number pattern using wildcard characters (dots). This has been resolved.
If the directory /hd/cfg/db/ was deleted accidentally, the system could not write any database files. As a result, any changes to the database were lost after the system reboot. Now, as a preventative measure for the files not to be lost, upon startup, the Tenor will check to see if the directory /hd/cfg/db/ is missing. If it is, the system will create a new /hd/cfg/db/ directory in which the database files can be written.
If a Digital Tenor received a STATUS message in response to an outgoing SETUP, it would have dropped the call. This has been resolved.
When an initial call was made using UDP (because transportType in SIPSG was set to UDP), and the user hit flash hook and dialed another number, the call may have been made using TCP. The call should have been made using UDP. This has been resolved.
When a Tenor (CRSP) was upgraded to P108 (which includes new IP to IP routing), the Tenor Configuration Manager gave an error/warning message about needing the advanced routing P108 license.This should not have occurred and has been resolved.
Port mapping using SIP did not work in P108. This is now working.
IVR types were not accessible using the New Routing. IVR type 0, 1 and 8 are now exposed.
The Tenor did not obey the transport specified in the REFER-TO header of a REFER message. Instead, it was using the transport type configured in the SIP Signaling Group to send the Invite out. This has been resolved.
After a call is up, the server was sending the Tenor a re-Invite with no SDP. The Tenor took this Re-Invite as a trigger to send a hold request to the far end. Instead, a regular re-Invite (with SDP) should have been sent to the far end. This has been resolved.
If a Tenor received a BYE at a session that did not exist, it would ignore the message. Instead, a 481 will now be sent in response to a BYE with non-existent call session.
A call tried to route out PRI, but there were no available channels. The return cause was Busy (17), and an alternate route was not attempted. This has been resolved.
If the Tenor received a request with SDP that did not contain annexb, then in response, the Tenor would improperly put annexb in the SDP. This has been resolved.
Upon startup, there is an option of hitting the "i" key via the RS232 interface to set a static IP address of the Tenor. Occasionally, the Tenor would not save the IP address correctly, and when it reboot, the IP address would show as 0.0.0.0 instead of the keyed-in IP address. This has been resolved.
When the Transport Type in SIPSG was set to UDP, it ignored the varconfig entry "SipTransportDefault" set to 1 (to use TCP for the SIP calls). This has been resolved for the varconfig entry to take precedence, resulting in the call being sent over TCP.
The PrimarySIPServer was restricted and unable to be configured. This has been resolved.
The Tenor stopped working when the command "st ds1 call" was issued. This has been resolved.
There was an IP address configuration problem on a new Tenor CMS. This has been resolved.
Several new changes/feature enhancements have been included for the Tenor's new Routing feature.
Inbound TG changed to Incoming From
OutboundTg changed to OutgoingTo
InboundMatchCriteria changed to IncomingMatchCriteria
NumberForDiversion changed to DiversionPilotNumber
DiversionContent changed to DiversionMatchCriteria
try restore database. Restores db.txt file from db.bak file, if it is available.
try backup database. Backs up db.txt file as db.bak file.
When new routing was enabled, and a user tried to access Hunt LDN, there was not a message stating that the hunt group was disabled. The following message now exists:
Error: This command is inaccessible in the current configuration.
An su login is required to access it.