Issues Resolved In Release 3.2.2; Issues Resolved - Aastra 6700i series Instruction Manual

Issues Resolved in Release 3.2.2

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.
Note:
Unless specifically indicated, these resolved issues apply to all phone models.

Issues Resolved

Issue Number
Configuration
DEF22868
SIP
DEF16955
DEF23199
DEF23233
DEF22974
DEF23257
DEF23258
19
Description of Fix
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.
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.
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.
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.
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.
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.
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).
RN-001037-02 REV03 – 06.2011