Issues Resolved in Release 3.2.2
19
RN-001037-02 REV03 – 06.2011
Issues Resolved in Release 3.2.2
This section describes the issues resolved on the IP Phones in Release 3.2.2
The following table provides the issue number and a brief description of each fix.
Issues Resolved
Note:
Unless specifically indicated, these resolved issues apply to all phone models
.
Issue Number
Description of Fix
Configuration
DEF22868
When the <mac>.tuz2 file is not successfully decrypted due to an unmatched
key or a corrupted file, there is no warning message displayed. Now the warn-
ing message “Bad encrypted cfg” is displayed when the <mac>.tuz2 file is not
successfully decrypted.
SIP
DEF16955
When the call is using Secure Real-time Transport Protocol (SRTP), the phone
didn't send PUBLISH packets or Real-time Transport Control Protocol
Extended Reports (RTCP-XR). Now the phones send PUBLISH packets and
RTCP-XR reports for SRTP calls.
DEF23199
The phone did not complete the call when a user dialed the destination using
an IP address. Now users can dial the destination using an IP address.
DEF23233
There was no secondary dial tone until the second digit was entered when the
live dial pad was on. Now the secondary dial tone is heard when the user dials
the first digit.
DEF22974
When the outbound proxy is configured on the phone and if the primary
proxy fails, the phone will restart after sending a SUBSCRIBE for as-feature-
sync. Now the as-feature-sync message is successfully sent out when the
backup outbound proxy is used and the phone does not restart.
DEF23257
When a Speed Dial key was configured to send DTMF according to RFC2833,
the DTMF “end” messages were incorrectly sent. Now each string of the RTP
messages with DTMF content end with three “end” messages and the time
between the RTP messages (i.e. the inter-digit time) is 40ms.
DEF23258
6739i: When a Speed Dial key is configured to send DTMF, according to
RFC2833, the “end” messages do not respect the time stamp. The time stamp
between the 2 digits increments correctly (720-800), however the first event
had the event duration as 204 instead of ‘0’, then incremented to 48, 640, 880
(end packet), which shifted the end packet out of range. Now the first even
starts at ‘0’, and then increments to 240, 480, 640 (end packet).
