[cisco-voip] ATA changes

[Fred Fern]

I'm not sure if this is part of the speed issue but ATA186 are 10BaseT while
ATA188 are 10/100BaseT



On 2/6/07, Robert Singleton < rsingleton at novateck.com> wrote:
>
> I've been troubleshooting faxing issues lately (and that is a whole
> 'nother thing) and along the way, it came to my attention that somewhere
> in one of my two recent upgrades (from 4.0 to 4.1.3, then applying sr4d
> to that), there was apparently an upgrade to the phone load for the
> ATA-18X. The web access to the old firmware was in the form of
> http://ipaddress/dev and was presented as a single page form. The newer
> version is more like the web access on the 7900 phones, a title page and
> several pages with information and editable parameters. On the face, it
> is definitely better, though it does break a couple of my scripts. :)
>
> What I'm asking the list if any of you have experienced two ATA problems
> that I only discovered during the last few days.
>
> First, and this is more of an irritant than a problem, but on the main
> page, the Phone DN fields don't display the actual DN, but rather the
> E.164 address for that line. This was confusing because I was working on
> fax machines and most of our fax numbers are ported numbers coming in a
> PRI and translated to the DN. The DN conforms to an internal numbering
> plan where basically all fax DNs are in the form of 2XXX9YY where XXX is
> the branch ID and YY is 00-99. Often I have two or more DIDs pointed to
> the same DN. All my reporting and CDR queries want the DN. So anyway,
> when I am marching through a bunch of ATAs adjusting parameters at 2AM,
> I have enough trouble keeping it straight without being shown the wrong
> info for the DN.
>
> The second thing is really a lot worse problem, though it really comes
> down to a political issue. The new image seems to change the ethernet
> port on the ATA to run 10MB half duplex. In the majority of my
> locations, this is no problem because the switch ports are set auto/auto
> as seems to be recommended by everyone I've talked to except for the
> contractor that maintains our network. They like to lock ports for
> telephones to 100MB full duplex. This is done to minimize alarms from
> devices that may legitimately renegotiate, such as those unfortunate
> enough to not be on POE switches, etc. That's a different argument and I
> I can see both sides.
>
> The problem is that I was unaware of the ATA image update (my bad, true)
> when something random caused some ATAs to reload. After they came back
> up, they no longer worked on any port in the affected switches. Not even
> a link light. We spent some days troubleshooting remotely with
> non-technical personnel, changed cables, sent replacements, verified
> that 79XX phones worked in those ports, etc, before someone thought to
> check the setting on the switch. In on instance, I had no paging in
> three branches from last Wednesday until late yesterday afternoon when
> we discovered the caveat. I have since found 3 or 4 of the 70 or so ATAs
> I have out there were in a similar condition, but they just happened to
> be in applications where the problem hadn't surfaced yet. Most are on
> switches that we have set to auto/auto regardless of what our contractor
> would prefer and so negotiated to 10MB half duplex and are working
> without issue.
>
> Robert
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20070206/6699cad4/attachment.html