[Asterisk-Users] Cisco 6.0 gripes

[John Todd]

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 at 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 at 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