(1) Short problem description:
Cisco Phone Crashes and Burns During SIP Session with multi-homed SIP
endpoints
(2) Longer problem description (what happens):
Cisco phone has a tendency to crash and burn when communicating with
multi-homed SIP endpoints (such as an Asterisk PBX with multiple
Ethernet interfaces or IP aliases). I do not know if Asterisk's
output messages in this scenario strictly adhere to standards, but no
other client I've run in the same scenario (Snom 200, X-Ten Lite, etc.)
has had this problem. Only the Cisco 7960 crashes out. Even
if the problem lies in the messages themselves, the Cisco should handle
it more gracefully than a crash & reboot.
(3) Possible solution (what did you expect):
If the first IP address listed on the Asterisk PBX box is the IP
address that the Cisco 7960 tries to connect to, and both are in the
same subnet, all is well. Also, if the Cisco is remotely located
(away from the same Ethernet as the Asterisk PBX) and you call upon the
PBX at its external IP address, there continues to be no problem.
(Assuming you use the fromdomain option in the asterisk SIP setup
record for the Cisco & create a DNAT rule on the router in front of
the Cisco such that the internal address destination gets rewritten as
the external interface of the Asterisk server...)
(4) How to reproduce (if possible / applicable):
It should be pretty easy. Set up a multi-homed Asterisk server by
using IP aliasing and try to communicate with the server using the
Cisco on the same Ethernet segment. Configure the Cisco in an
internal-only address space, but make the default gateway and the
primary interface on the Asterisk server is in the internet-routable
address space. SIP signaling will work, but as soon as audio data
is passed, the phone will crash.
(5) Workaround used currently (if applicable):
See above #3.
(6) The behaviour wanted exists in product (name manufacturer and
product as exactly as possible):
Snom 200 ( a hardphone) , XTen Lite Soft Phone ( a softphone)
(7) Would you classify this as:
(A) Bug/malfunction: Can not deploy before fixed
Category A, in terms of a mass deployment. I cannot imagine
sending this phone out into the field with this kind of scenario
outstanding. Category C, in terms of internal use in a tightly
controlled network.
(9) Contact Information
Matthew Hardeman <mhast@SPAM.papersoft.com>
(10) If you have filed a DDTS/CARE case, what case number is it
There is a Cisco case EE225816
(11) Report:
Message-Id: <p052106b3bb34e3fe9dec@loligo.com>
Date: Fri, 11 Jul 2003 15:02:09 -0700