Filter
Top Products
Special offers from our partners!
Find Replacement BBQ Parts for 20,308 Models. Repair your BBQ today.
Internet Service Node (ISN) 2.0 Release Notes
Page 21
Identifier Comp. Severity Headline Release-note Enclosure
CSCdw39759 CCM 3
INFO message
should be used for
ringback tone
generation for IP
phone call transfer
Problem Description: When a call coming from
IOS gateway and terminates to IP phone and
is being transferred, the caller is not hearing
the second ring back tone (cscds11354).
Change has been made in both call manager
and IOS gateway to use h225 user info
message to send the q931 signal IE to request
the IOS Gateway to turn on and off the ring
back tone. But it turns out that the older
version of H.225 standard (dated 02/98) had
typo error in session 7.3.6 which stated User
Information message should be used, and the
latest H.225 standard (dated 11/00) corrects
the error by stating that Information message
should be used.
In order to correct this problem, both Call
Manager and IOS gateway needs to make the
change at the same time to use the correct
message type, there is a ddts cscdw39337
opened to keep track of this problem for the
IOS gateway, therefore these two ddts are
dependent on each other.
Since the user information message is being
only used between Call Manager and Cisco
IOS Gateway at this time, there is no
immediate impact on the original functionality
and the functionality of both products, but we
should use the correct message in the near
future.
Workaround: None. This has been fixed in
CCM 3.3
CSCdx26761 GW 3
Need CLI to disable
h225 TCP keepalive
timeouts
Currently IOS enables TCP keepalives on the
H225 VoIP call control session. This cannot be
disabled. These keepalives, zero byte tcp
packets, are sent each minute and will tear
down the tcp session after 4 attempts which
clears the call. The noticed symptom is that
calls in progress are dropped after 5 minutes if
these keepalives are not acknowledged. The
TCP keepalives may be blocked in certain
circumstances such as: - while running the
VoIP gateway in SRST mode and the WAN
link to the CallManager fails - traversing
firewalls which may be blocking the TCP
keepalives In the latter case, this should not
occur but has been noticed in some cases.
Workaround: None