So, after playing with 6.0 on the Cisco 7960 and 7940 platforms, I
have the following gripes, which I've sent to a very clueful Cisco
person already. Mind you, I love the Cisco 79xx series phones, and
currently they are what I recommend to anyone who wants a 'real' IP
phone. I just cringe
- Speed dials. It's nice to now have speed dials in the line
appearances that don't have lines in them.
PROBLEM: They're not configurable through the SIP*.cnf files, or at
least it's not documented in the SIPPhoneReleaseNotes.6.0.pdf
document.
- Ringtones. So, we're hobbling towards functionality, maybe,
someday. Now I have four ring "patterns" to select from
(Bellcore-dr1 through dr4, since dr5=dr1 I don't count it.) So now
we're at the functionality level that the ATA-186 has had for more
than a year.
PROBLEM: We have custom ringtones. Allow them to be used, please,
in a dynamic way. If the tftp transfer isn't done within .3 seconds,
then just revert to the default ringer (if that is indeed the
concern.) Cache the last 3 or 4 ringers for speed; we can safely
assume that they're not going to change.
- Intercom/pager: fixed in a rather inelegant way, with critical
security concerns.
Firstly: why can't these be configured in the .cnf files? Nobody
will listen to the mail about "Instructions for turning on the
intercom on your phone."
Secondly: Here's the issue, which should be startlingly obvious to
anyone using these phones: until a phone-based method for refusing
INVITEs from anything other than an authorized list of proxies is
established, then it is possible for anyone else who has clear IP
connectivity to that device to silently snoop in that office. CISCO
HAS CREATED A SECURITY HOLE A MILE WIDE. This will appear on Bugtraq
within days (not from me, though.) The inability for a device to
REFUSE invites to an auto-answer extension is ill-advised. I wanted
pager and intercom, but in a secure manner - this is the opposite of
secure. The reality of putting SIP phones on the "real" Internet
exists - don't assume that devices will be behind a "firewall".
Inside an enterprise is the worst security risk - can you imagine
what happens when people figure out that they can call
"1234@thebossphone.foo.com" and get a silent bug on the desk of the
CEO? Is anyone under the impression that people won't have their
x-ten clients pointed at this the instant it's implemented on
anyone's phone?
I perhaps would have chosen a slightly different way to do it,
rather than having a whole line given over to the task, since this
obviously doesn't scale to 7905/7912 phones since they are single
line only. A per-SIP proxy flag like this:
proxy1_accept_intercom: [yes|no]
proxy1_accept_pager: [yes|no]
[etc. etc.]
proxy6_accept_pager: [yes|no]
general_accept_intercom: [yes|no]
general_accept_pager: [yes|no]
proxy1_intercom_meta_identifier: "intercom-"
proxy1_pager_meta_identifier: "pager-"
[etc. etc.]
would have worked better. That way, the user (administrator,
whatever) can allow or disallow each proxy from being able to create
pager or intercom events on a line. A "general_" identifier would
account for all INVITEs that did not come from one of the known
proxies. Additionally, any pager or intercom events need to be
prefixed by a meta-identifier in front of the extension (user) of the
SIP INVITE. Example: "To:
<sip:pager-1234@204.91.156.10;user=phone>;tag=as54c07f31" This may
be a particularly ugly way of doing it, and I'm sure there are RFCs
that cover the topic in a much more flexible way than I describe,
however, I would hate to see this turn into yet another PKI nightmare
- trust the passwords you have with the proxies. You can elect to
trust your proxy, which carries at least some authentication burden
that is outside of the phone. (Note: there is a larger issue here,
which is that the phones should be configurable to accept RTP and/or
SIP messages from ONLY their proxies. It breaks the end-to-end
nature of SIP only if CONFIGURED that way. Reality says users will
turn off their phones when the first spam callers start to sweep the
'Net for vulnerable phones, so something has to be done.)
JT
