David Girardin
    I am not able to upgrade a 1692 polycom to the 1.0 load. It gets stuck looking for a 004f2e43b97.cfg file not found. The MAC address of the phone. It downloaded the 1692upgrade.txt then the 46xxsettings.txt file. Then gets stuck here.

    Using a HTTP server.
    John Walshaw
    [Kaman Corporation]
    I received a 1692 today and am working with it in the lab... I'm having some trouble too, but I think you've got further than me. What DHCP options you have? Once I can get as far as you, I can help resolve the issue you are describing.
    David Girardin
    All I have in the DHCP scope is a dummy Callserver IP and an HTTP server address. I am working on a small test area also. I have tried it in production but can not even get it to grab an IP address there. But we have more security turned on there also.
    John Walshaw
    [Kaman Corporation]
    By pressing "* to prgram" at initial boot, the # key enables the following values to be seen (will show if/what it has pulled in from DHCP)

    Phone (IP)
    CallSv
    CallSvPort
    Router
    Mask
    FileSv
    FileSv Type
    Boot Server User name
    Boot Server Password
    8021.Q
    VLANID

    I have 242 options set to "MCIPADD=x.x.x.x,MCPORT=1719,HTTPSRVR=x.x.x.x" and verified that the phone is pulling this information in. I have yet to get the 1692 to read files from the our very functional http server (we have many 96xx phones in production using it today).

    I noticed that FileSv Type supports values of:

    FTP=0
    David Girardin
    Ture, sorry I did manually end up setting mine to HTTP=2.
    John Walshaw
    [Kaman Corporation]
    In my case 1692 is booting and after waiting at "Updating initial configuration" states "Could not contact boot server, using existing configuration".

    Any ideas? Is it just me or is the 4690/1692 very badly documented?

    BTW1 from what I can understand the .cfg can be named 000000000000.cfg as that is the default file unless you want a mac specific configuration.

    BTW2 The issue that you are having with the cfg file may be realted to the absence of a trailing carriage return at the end of the last line. This is common in UNIX, if an /etc/hosts file is missing the CR at the end of the last line of the file, it will not process the line.
    David Girardin
    This is what is in the .cfg file. I did play with the one in the HTTP server and will double check the carriage return. I may have left it out with all of the playing.

    I assume the < or > equals a CR?










    John Walshaw
    [Kaman Corporation]
    A CR is the enter key on your keyboard :P

    If you open the file in a program that diplays 'Visible spaces' (like Textpad), you will see all of the characters that are not usually visable (see attached).
    Glenn Copes
    I've been checking this site for sometime, just thought i would take the time to register as im having very similar issues with the 1692. =(

    Im using the "February 1, 2010" edition of the 46xxsettings.txt file, which mentions it supports the "1692 telephone H.323 software release R1.00"..

    Issue im having is that the phone doesnt seem to be picking up or using any of our dhcp option 242 settings (which work fine with our 9620's).
    Is it true that this particular model needs all of the settings manually entered??

    I havent been able to find any .bin files for this particular model. Do the 16xx series .bin files work for the 1692? From what i've read it does not..

    Does anyone have the appropriate .bin files for this model?

    Edit:
    Also, can someone explain what the fields below are used for? We are running CM version 4

    Boot Server User name
    Boot Server Password
    John Walshaw
    [Kaman Corporation]
    Regarding your "phone will not pull 242 option from DHCP" comment, have you verified this? Use the '* to program' menu and once at the Phone prompt, press # to increment through th menus. Verify that absolutely no information has been received, i.e. no IP, no, Call Sv, etc.

    According to the documentation, the only thing that has to be configured manually, is the FileSv Type. i.e. set it to 2 if you are using HTTP. The Boot Server User and Pass, which default to 123, do not appear to accept null values. This might be the problem if the phone is attempting to send user 123, pass 123 to the http server (which has anonymous access enabled). I have a ticket open with Avaya at the moment and it seems that the knowledge base on the 1692 phone is close to non-existant. If only Avaya would publish documentation for this phone, internally and/or externally.

    Regarding files that are available on the Avaya web site, if you go to support.avaya.com and set product to 'Conference Phones' you'll notice that Avaya have not posted anything regarding administration or instlation in their documentation section. Instead, go to the download section, where you will find a number of files to download, including a 1692upgrade.txt, which is the only file that the phone looks for when it contacts the file server. Everything else, including the 46xxsettings.txt file gets called from there.

    Still I have not been able to get the 1692 to read a single file from our http server, so all of the above is theory intil proven otherwise.
    David Girardin
    I have had it grab the upgrade file and the settings file. But it does nto finish the upgrade.

    I will be dropping one of to a local Tier 3 engineer near us for him to play with and get working in his lab. Then hopefully get some info on what is needed.
    Inactive Forum User
    I've been struggling with this same problem for the last 24 hours. We bought a few new 1692's and 2 of them decided to throw the "error loading 0004f2e43d27.cfg" message. Couldn't get them out of this loop for the life of me, until I pressed * to set my values manually and changed the IP. Literally, that's all I did, change the IP to something I hadn't used before and it worked perfectly. Of course, once it came up I did a reset on it (mute button then RESET# (73738#)) to make sure it pulled DHCP and all other correct values. So far so good.

    Also, make sure you have option 242 set in your DHCP scope, without this it's a mess.
    John Walshaw
    [Kaman Corporation]
    I'm still stuck at getting a 1692 to read files from an http server.

    ePrizeLLC, what did you set your FileSv Type to (under the '* to program' menu) and can you paste your 242 options please?

    Also, can you attach your 1692upgrade.txt, 000000000000.cfg, .cfg files?

    You and DaveG seem to be ahead of the curve! ;)
    John Walshaw
    [Kaman Corporation]
    This just in from Avaya... they state that they are aware of problems with the 1692 and that there will be a release in May 2010 to resolve. Pretty disappointing information.
    Glenn Copes
    Hope that fix helps.

    I got my hands on the correct 1692_000100.zip file which contains the 000000000000.cfg that you have been talking about above. I have uploaded these via tftp, plug in the 1692, manually set to HTTP and waited... and waited. Doesnt get very far at all before it begins to loop.

    Ive found if i hit * to program and set all settings (phone ip, router, subnet, vlan etc etc) it does appear to boot up and go through its sequences faster... but it still wont get to the enter ext screen.

    Very interested to see what DaveG has in his .cfg's or other files to get further. Thnx =)
    John Walshaw
    [Kaman Corporation]
    GlannC, can you paste your DHCP Server 242 options for the subnet your 1692 is on? Also are you using VLANs to seperate voice from non voice? If so, please post the 242 options for both DHCP scopes/subnets.
    John Walshaw
    [Kaman Corporation]
    I have discovered a problem with 1692upgrade.txt. It is as follows:

    SET APPNAME 1692_000100.bin
    GOTO 46xxsettings.txt


    This is actually incorrect and it should read:

    SET APPNAME 1692_000100.bin
    GET 46xxsettings.txt


    This doesn't change the fact that it doesn't appear to ever retrieve the 1692upgrade.txt file!!! So I'm still not any further along than before.
    Christopher Trown
    [University of Oregon]
    I solved the problems with this phone. The firmware that ships with the set is increadibly broken, as some of you have noticed. First, it tries to download firmware via FTP, which I hadn't set up.

    To get the latest load onto the phone, I set up the IP information manually. No DHCP. The key step for me was to make set the phone to use TFTP to download firmware instead of FTP(The default). HTTP would probably have worked too. Once I set all this up, it downloaded it's firmware just fine. After it loaded it's firmware I set everything back to DHCP. The regular DHCP options I had for all my other phones were fine and worked with this set.


    Once the latest firmware is loaded, the set behaves like we expect. I still kept the download setting to HTTP, however.

    Hope this helps.

    Chris...
    John Walshaw
    [Kaman Corporation]
    For 1692 currently running 217 I have monitored the specific HTTP GET and PUT traffic using Microsoft Network Monitor. For a complete boot of the 1692 here is what I found. You may be left scratching your head as I am.

    1692upgrade.txt is the only file present on the IIS web server. Here are the results:

    GET /1692upgrade.txt
    GET /46xxsettings.txt
    GET /SCREENSAVERDEFAULT
    GET /SCREENSAVEDONE
    GET /END
    GET /bootrom.ld
    GET /0004f2e44f15.cfg
    GET /000000000000.cfg
    PUT /0004f2e44f15-boot.log
    GET /1692upgrade.txt
    GET /46xxsettings.txt
    GET /SCREENSAVERDEFAULT
    GET /END
    GET /bootrom.ld
    GET /bootrom.ld
    GET /0004f2e44f15.cfg
    GET /000000000000.cfg
    GET /0004f2e44f15-phone.cfg
    GET /0004f2e44f15-directory.xml
    GET /000000000000-directory.xml


    This is strange considering that the file has a syntax error and states GOTO instead of the typical GET:

    SET APPNAME 1692_000100.bin
    GOTO 46xxsettings.txt



    • 46xxsettings.txt is not present but the phone still requests it
    • Requests for DEFAULTSCREENSAVER SCREENSAVEDONE and END which are GOTO lines found in a typical 46xxsettings.txt file that doesn't exist on this web server
    • Does not appear to request the 1692_000100.bin firmware file
    • Requests a file called -phone.cfg that is not supplied by Avaya
    • Requests a file called -directory.cfg that is not supplied by Avaya
    • Requests a file called 000000000000-directory.xml that is not supplied by Avaya
    • Attempts to put a -boot.log which will fail unless anonymous write access is enabled on wwwroot


    So I then modified this file with a better suited version of 1692upgrade.txt that I adapted as follows:

    ############################################################
    ## ##
    ## AVAYA 1692 IP TELEPHONE SOFTWARE UPGRADE CONFIGURATION ##
    ## *** Feb 01, 2010 *** ##
    ## ##
    ## This file upgrades the following telephones ##
    ## to the indicated releases: ##
    ## 1692 - Release 1.0000 ##
    ## ##
    ############################################################
    ## ##
    ## BACKUP APPLICATION VERSION NUMBERS ##
    ## 1692 - Release 1.0000 ##
    ## ##
    ############################################################
    ## ##
    ## PHONE APPLICATION VERSION NUMBERS ##

    ## 1692 - Release 1.0000 ##
    ## ##
    ############################################################
    #
    #
    ############################################################
    ## Check backup application version ##
    ############################################################

    ##IF $MODEL4 SEQ 1692 goto BACKUPAPP1692
    ##goto END

    # BACKUPAPP1692
    IF $BOOTNAME SEQ 1692_000100.bin goto PHONEAPP1692
    SET APPNAME 1692_000100.bin
    goto GETSET

    ############################################################
    ## Check phone application version ##
    ############################################################

    # PHONEAPP1692

    SET APPNAME 1692_000100.bin
    goto GETSET


    ############################################################
    ## Get additional configuration files ##
    ############################################################
    # GETSET
    GET 46xxsettings.txt

    # END


    Here are the results of testing with this file:

    GET /1692upgrade.txt
    GET /GETSET
    GET /bootrom.ld
    GET /0004f2e44f15.cfg
    GET /000000000000.cfg
    PUT /0004f2e44f15-boot.log
    GET /1692upgrade.txt
    GET /GETSET
    GET /bootrom.ld
    GET /bootrom.ld
    GET /0004f2e44f15.cfg
    GET /000000000000.cfg
    GET /0004f2e44f15-phone.cfg
    GET /0004f2e44f15-directory.xml
    GET /000000000000-directory.xml


    Things to notice:


    • Does not appear to request the 46xxsettings.txt
    • Requests a file called GETSET


    Notice that the 1692 has not processed the 1692upgrade.txt and when encountering the 'goto GETSET' command has directly performed an HTTP GET for file called GETSET!! Shock horror! This explains why the Avaya supplied 1692upgrade.txt likes the GOTO command.

    Then I removed the 1692upgrade.txt file and found the results to be identical to the initial test.

    Then I replaced the 1692upgrade.txt and added a CR to the last line. Again, the results were identical, which tells me the following:


    • The phone will always request 1692upgrade.txt and 46xxsettings.txt
    • The syntax that the 1692upgrade.txt uses uses the GOTO command instead of GET
    • If 1692upgrade.txt exists AND references a different file (using the GOTO command), the phone will request that file and not 46xxsettings.txt


    I then added all of the files that Avaya suggest as follows:

    000000000000.cfg
    1692Localization DIRECTORY with language sub-directories
    1692upgrade.txt
    1692_000100.bin
    bootrom.ld
    phone1_vcvr.cfg
    release.xml
    sip_backup.cfg
    46xxsettings.txt


    Again, the results were identical.

    See the Eurica post below for IIS 6 configuration needed to resolve this.
    John Walshaw
    [Kaman Corporation]
    Eurica!!!!!

    The following config changes on your IIS 6 web server will finally allow the downloading of version 100 firmware:


    • Go into the properties of the default web site
    • Go to the HTTP headers tab
    • Click MIME types
    • Add entries for cfg, ld (see attached)


    Your IIS http server will now allow these file types to be accessed via HTTP and the phone will finally do a firmware upgrade!!

    The only other pre-req is manually setting the File Server Type = 2 (HTTP) on the phone's '* to program' menu. DHCP can still be used.

    This is the root casue that prevents files from being downloaded. Unfortunately, Avaya have chosen non standard file extensions and have not included any HTTP server re-req info in their release notes. Is MIME type info referenced in any of their documentation?

    I will repeat the tests monitoring the HTTP get/put with firmware 100.

    Interestingly the 1616 phones need a type "hex" added to the MIME types list also as they look for this file during boot. My 1616, which I thought had upgraded fully firmware, has now downlaoded bm32a2_1.hex and saved to flash... this tells me that it was a partially upgraded phone until making this final and important change.

    EDIT: "ld" is the missing file type in order to complete the firmware upgrade. "cfg" is not related to firmware upgrades. It's still unclear what the "cfg" files accomplish and if they casue problems when deployed in an H.323 environment.
    John Walshaw
    [Kaman Corporation]
    For phones that have been upgraded and are running firmware 100 I have monitored the traffic using Microsoft Network Monitor.

    All files supplied from Avaya in the standard zip (1692_000100.zip) file without any modifications are on the wwwroot including a recent 46xxsettings.txt.

    GET /1692upgrade.txt
    GET /46xxsettings.txt
    GET /SCREENSAVERDEFAULT
    GET /SCREENSAVEDONE
    GET /END
    GET /bootrom.ld
    GET /0004f2e44f15.cfg
    GET /000000000000.cfg
    GET /1692_000100.bin
    PUT /0004f2e44f15-boot.log
    GET /1692upgrade.txt
    GET /46xxsettings.txt
    GET /SCREENSAVERDEFAULT
    GET /SCREENSAVEDONE
    GET /END
    GET /bootrom.ld
    GET /0004f2e44f15.cfg
    GET /000000000000.cfg
    GET /bootrom.ld
    GET /phone1_vcvr.cfg
    GET /sip_backup.cfg
    GET /0004f2e44f15-phone.cfg
    GET /0004f2e44f15-directory.xml
    GET /000000000000-directory.xml
    GET /SoundPointIPWelcome.wav


    Things to notice:


    • The phone still suffers from processing a GOTO as a GET rendering the 46xxsettings.txt useless
    • Despite being upgraded, the phone actively downloads the bootrom.ld and 1692_000100.bin despite already being stored in flash. If you have many 1692 phones this could consume quite a bit of WAN bandwidth during a network region phone reboot. I'll most likely test to see if this occurs with 1616 and 9640 phones.
    • References to numerous files that are not documented


    After the upgrade and a couple of boot cycles on firmware 100 (shown above) the phone does not appear to register and periodically shows this message

    2011-Registering No signaling connection


    Upon performing a R E S E T on the phone (mute 73738 #) the phone seems to then have some trouble and gives a cannot contact boot server message but does eventually get to a Ext= prompt and does register upon entering credentials.

    One additional boot cycle and the phone is back to

    2011-Registering No signaling connection


    Is the phone trying to connect in SIP mode instead of H.323 mode? Perhaps removing the .cfg files will help...

    I do not advise upgrading to firmware 100 until this is resolved.

    More testing to follow
    John Walshaw
    [Kaman Corporation]
    Removing the .cfg files seems to be a positive step. The phone boots and attempts to retrieve all files referenced in the previous post. The absence of the .cfg files triggers the phone to display message:

    Could not contact boot server, using existing configuration


    But the phone does have a successful boot and complete H.323 registration on every boot cycle. The presence of .cfg files seems to prevent the phone from being capable of performing a H.323 registration and is possibly related to SIP registration.

    I have also tested removing all files from wwwroot as there is little point in having files download post firmware upgrade because the phone is incapable of processing them. This is because we already established that the 46xxsettings.txt file is ineffective and does not get processed. The 1692 literally does not support the use of the standard settings/script files. I suspect that both 217 and 100 firmware have a hardcoded copy of 46xxsettings.txt due to the HTTP GET calls to /SCREENSAVERDEFAULT/SCREENSAVEDONE and /END that occur regardless of if the file exists on your http server. We know this because of the bug that is interpreting GOTO as a GET, which is a bug. I'd guess this is a relic of software development that was not commented/removed from the code.

    In summary, customizations are not possible on the 1692 when using 217 or 100 firmware.

    In reality our production environments will have DHCP option 242 and a 46xxsettings.txt file for our other phone models, so my recommendation is to do firmware upgrades in a controlled environment and not to deploy any 1692 files onto production http servers.

    When the next firmware is released for the 1692, we may have a phone that can retrieve and process files correctly and there might be supporting documentation for the files so we know what to do with them.
    John Walshaw
    [Kaman Corporation]
    In Summary (Updated):



    • Firmware upgrades on 1692 should be done in controlled/non-production environment

    • Firmware and settings files for the 1692 should not be deployed on the production HTTP server

    • In an HTTP environment, File Server Type must be set manually to 2 on the ‘* to program’ menu.

    • On an IIS 6 web server, file type “ld” and "cfg" must be added as a supported file type under MIME Types (I discovered this is true for file type “hex” on the 1616 phone also!) in order for the firmware update to be possible

    • The 1692 requires 46xxsettings.txt for the firmware upgrade and will use a cached copy on subsequent boot cycles if it does not exist.

    • Once firmware is updated re-deply in production without any of the Avaya supplied 1692 firmware or configuration files used in the above steps

    • The 1692, the .cfg files should not be deployed for non-firmware upgrade boot cycles in environments that require the 1692 to perform a H.323 registration as they seem to be what trigger the phone to go into SIP mode and prevent H.323 registration from being possible. The use of .cfg files on IIS6, requires adding them as supported file types (see previous bullet)

    • The absence of any files on the http server, including .cfg files, will trigger ‘Could not contact boot server, using existing configuration’ message and can be ignored.

    • Many files are referenced but not provided by Avaya nor are they documented: GET /0004f2e44f15-phone.cfg GET /0004f2e44f15-directory.xml GET /000000000000-directory.xml GET /SoundPointIPWelcome.wav

    • The 1692 is incapable of processing standard script file commands in the 1692upgrade.txt or 46xxsettings.txt. GOTO is interpreted as GET. GOTO SCREENSAVERDEFAULT GOTO SCREENSAVEDONE GOTO END are interpreted as GET /SCREENSAVERDEFAULT GET /SCREENSAVEDONE GET /END





    I have asked Avaya to escalate to their development team and that resolution to the issues identified be incorporated into the next release, scheduled for release in May 2010.
    Glenn Copes
    Alot of info since my last visit! Thanks for continuing to look at this jjwatmysel. :D

    In our environment we dont use an IIS server to host the config files, so due to this i havent been able to try the ideas in your more recent posts.

    In my tests i've attempted loading the contents of the bin file to the /tftpboot directory on the avaya lsp gateway.. which doesnt work so far.

    Am i understanding this correct, that the only way to get the 1692's to work is to use IIS?
    John Walshaw
    [Kaman Corporation]
    At a minimum, I'd suggest the following files be temporarily loaded

    bootrom.ld
    1692_000100.bin

    If the firmware upgrade is not triggered, then one additional file is temporarily needed:

    1692upgrade.txt

    If it still fails, then try adding this file temporarily:

    46xxsettings.txt

    If you get 'Could not contact boot server, using existing configuration’ it is normal as it could be one file of the long list shown on the previous post that could not be found... and will most likely be a file that you shouldn't deploy, i.e. always ignore thise message.

    The key is to have files on a file server temporaily in order to perform the upgrade only. There is no point having files deployed for non upgrade boot cycles, when the files are not used/needed and be having them present casue problems (like trigger the phone to go into sip registration mode). This only applies to 1692 settings and firmware files due to the issues.

    Hope this helps.

    October, 2010: UPDATE ON THIS NOW THAT 110 is out. You should be able to deploy ALL of the files to your production HTTP web server, perform upgrades and successful phone boot cycles without any modifications to the files from Avaya. At minimum, the phone needs to have "Filesv Type = 2" and "VLAN = ".
    Mary Grace Alibania
    In my case, I just use a tftp server and point to 1692_000100 dir where all files downloaded from avaya resides including the 46xxsetting, I use * program to point to my tftp server, chose 1 for tftp and after upgrade viola, the 1692 is working fine... :)
    John Walshaw
    [Kaman Corporation]
    As of Sept 30, 2010 R1.1.0 has been released. This includes documentation which is a SIGNIFICANT addition to what was previously VERY poor. The readme does show that the 46xxsettings.txt issues are resolved, although I have not tested this yet. I am hoping that the new 30 page Quick Start guide is going to silence all of our complaints about the 1692s. Let me know what you all think. :)
    Fawad Sabir
    [Supanet]
    Hi,

    I have just upgraded the conference phone and i think ive broken them. Basically it went through the motions and downloaded and verified the firmware and when it comes up it says it has the version app=1692_00110.bin running but it just cycles round and round not allowing me to log into the phone.

    Anyone having any similar problems.

    TIA
    John Walshaw
    [Kaman Corporation]
    Use the "* to program" and verify you have your VLAN set correctly. Also, if you are using IIS as the http server, make sure you added the lld, bin as MIME types as described earlier in this post. I have a number of phones on the new firmware. I have not implemented any customizations yet and copied all files provided to the file server.
    Fawad Sabir
    [Supanet]
    Use the "* to program" and verify you have your VLAN set correctly. Also, if you are using IIS as the http server, make sure you added the lld, bin as MIME types as described earlier in this post. I have a number of phones on the new firmware. I have not implemented any customizations yet and copied all files provided to the file server.

    Yep i have checked that too.. i have had to downgrade the firmware but it still seems to be knackered.. keeps on rebooting and cycling around.. :(
    John Walshaw
    [Kaman Corporation]
    Is this your only 1692 or do you have others that have been upgraded successfully?

    Is your firmware server http, ftp, or tftp and are you certain all of the files can be retrieved? i.e. paste the full URL of each firmware file (.ld, .bin, etc) in your browser and verify that the file can be retrieved. This way you know that you are serving files correctly.
    Con Nicolis
    [NSC]
    I have the same pain.

    I could not configure these phones to register with the S8800 servers we are deploying. It kept looking for 30.60.0.202 as the call server address.

    So I decided these must need to be upgraded. I tried to go to 110 as that was the latest firmware I found on the Avaya website.

    I used the existing HTTP production servers we had for our 9630 IP phones. Nothing , no luck with either manual configuration or DHCP.

    I then programmed the phone to go to my laptop using TFTP but I made sure I was on the same subnet as the 1692 and this worked and I have managed to upgrade all of them to 110.

    Now the problem I am having is out of the 30, two of them DHCP correctly and register and you can use them without a problem. The rest just cycle, they NEVER register or at least get the Ext OK prompt. When I check the settings on the phone, everything looks normal and I can ping the phone from the call server address (S8800). This is just bizarre.

    I cannot mute R E S E T the phone in this state, all I can do is blank everything out but this does not work.

    Any suggestions would be great thanks.
    John Walshaw
    [Kaman Corporation]
    I have the same pain.

    I could not configure these phones to register with the S8800 servers we are deploying. It kept looking for 30.60.0.202 as the call server address.

    So I decided these must need to be upgraded. I tried to go to 110 as that was the latest firmware I found on the Avaya website.

    I used the existing HTTP production servers we had for our 9630 IP phones. Nothing , no luck with either manual configuration or DHCP.

    I then programmed the phone to go to my laptop using TFTP but I made sure I was on the same subnet as the 1692 and this worked and I have managed to upgrade all of them to 110.

    Now the problem I am having is out of the 30, two of them DHCP correctly and register and you can use them without a problem. The rest just cycle, they NEVER register or at least get the Ext OK prompt. When I check the settings on the phone, everything looks normal and I can ping the phone from the call server address (S8800). This is just bizarre.

    I cannot mute R E S E T the phone in this state, all I can do is blank everything out but this does not work.

    Any suggestions would be great thanks.

    Well it sounds like your firmware upgrades were "complete" as you reverted to TFTP after trying HTTP. Something to keep in mind is that if you are using IIS for HTTP upgrades that there are MIME types you need to add in order for the .bin and .ld files to download successfully. Avaya does not have that documented. In terms of the phone booting on your production network, are the phones still configured to use TFTP becasue 110 defaults to HTTP. If by chance they are HTTP and if you did not remove the firmware files from your HTTP server, the phones may be stuck in a loop doing partial firmware downloads, just like they were when you first tried using HTTP. The issue with phones booting is that I beleive they download the firmware files despite already being upgraded. I monitored traffic and saw this. So it may make sense to verify that you have removed the 1692 firmware files from your HTTP server and retest. As you can see, the 1692 phones are VERY sensitive and not forgiving, like the 96xx are.

    Next, I would check teh 1692 settings under "* to program" and 0.0.0.0 out all of the IP address information and manually set the correct VLAN number of your voice network. They default to zero, which seems to serve NO purpose as many switch brands do not use a zero vlan.

    Verify your DHCP 242 option is on the scope for the VLAN you want the phone to be on.

    That's about all I can think of. Avaya will allow you to open a ticket with them on this, but there seems to be more information on this thread than you will get from them over the phone.
    Con Nicolis
    [NSC]
    Hi jj,

    thanks for your reply. I'll be honest, I am baffled how anyone can get these things working. They do not play the game.

    Once upgraded to 110 whether you dhcp or manually configure they do not register. It is quite bizarre. When you DHCP and then get into the * prompt to see what is going on the ip address is missing.

    When manually configured and you get into the * prompt there is nothing wrong the correct settings are all there. I did what somebody suggested above which was to remove all the files from the HTTP server. I have tried the S8800 and an Apache server for HTTP and I get the same result.

    Now out of the 30 I got another one out of the box which had a version 000217 which I don't even see on the Avaya website and this one works.

    Does anyone know how to get this firmware ? Only 110 is on the Avaya website as the latest.

    I am slowly losing my mind over these phones and I am close to doing a Russell Crowe :eek:
    Con Nicolis
    [NSC]
    Ok jj, I finally logged a fault with Avaya as I had no other option and I received a new firmware 251 and voila !!! This works :)

    You 0 everything out using * and let it go and it works.

    I moved it to another VLAN and it seemed to be ok , I have upgraded and registered 12 of these as I type this message and have 16 to go but I am confident that this new firmware is alot better than the previous versions.
    John Walshaw
    [Kaman Corporation]
    Did they give an explanation for providing an unpublished version? Also, the version number is out of sequence and 120 should be next, so it's almost like they provided the "in case of emergency, break glass"
    Con Nicolis
    [NSC]
    This is not a released version , it is a version they created for another customer who said they had the same problem. They should release this version.

    If you want it just send me a message , the whole package is 7.5Mb.
    Riaz Shah
    [OFT]
    Hi
    Can someone provide a link to the firmware 251 that Major is talking about. I have spent all day today trying to get this damn conf phone to register without success.
    Ian Grey
    [Provident Financial]
    WE have fourteen of them bought relatively recently (about 6 months ago). They report as having SW File 1692_000217.bin installed. We have to force them into their correct VLAN in order to come up and they also fail miserably to get to the file server in the process, even though we are using DHCP scope 242 and forcing them to HTTP. (Not that we have any useful 1692 files on the file server anyway at present and the reference to 1692 is starred out in the 46xxsettings file based on June 7th 2010)

    We have to dedicate a specifically configured network port to them as we generally use 802.1X and the spider phones don't support that.

    What we have noticed receently is that if they are not used for several days they still appear to work but no dial tone is heard and no speech path occurs. A reboot sorts that but it is not the sort of thing we want to have to do in the boardroom under the watchful eye of our Directors!

    Has anyone seen a similar problem?
    Jim Johnson
    [Acme]
    Has anyone seen a similar problem? I haven't seen that problem, but to get my 1692's to even register I had to move them to my data vlan so that they were forced to route to my PBX. For some reason being in my voice vlan on the same switch as my PBX would not work, they had to route to the PBX to work. Sounds crazy, but it worked for me, maybe it'd help you too?
    Scott Roberts
    [CCH-SFS]
    WE have fourteen of them bought relatively recently (about 6 months ago). They report as having SW File 1692_000217.bin installed. We have to force them into their correct VLAN in order to come up and they also fail miserably to get to the file server in the process, even though we are using DHCP scope 242 and forcing them to HTTP. (Not that we have any useful 1692 files on the file server anyway at present and the reference to 1692 is starred out in the 46xxsettings file based on June 7th 2010)

    We have to dedicate a specifically configured network port to them as we generally use 802.1X and the spider phones don't support that.

    What we have noticed receently is that if they are not used for several days they still appear to work but no dial tone is heard and no speech path occurs. A reboot sorts that but it is not the sort of thing we want to have to do in the boardroom under the watchful eye of our Directors!

    Has anyone seen a similar problem?

    Similar situation for me. Installed 12 1692's and have experienced loss of audio / dial tone after the phones sit idle for a couple days. Haven't had time to investigate or troubleshoot the issue other than reading comments here.
    :D
    Bryan Benway
    [BP]
    Has anyone gotten this firmware? Have 13 to deploy and non are working right.
    Alaa Najim
    [Al Moayed Group]
    I have checked this thread several times, but there is no solution to the problem yet. I have 2 1692 units and both of them stuck at . Initially they came with 217 load, I was facing the problem of discovering pre-configured call server. I upgraded its firmware to 110 and it got stuck at error loading mac.cfg. From the file server log I can see that the unit requested and uploaded the bootrom.ld file. After the restart the unit didn't request for the APPNAME 1692_000100.bin. Even the unit is not pingable. :mad:

    Any idea how to sort out this problem, or any work around.
    Glenn Copes
    Hey all

    If anyone has a working copy of this new 217 or 251 version firmware, could you please email me a copy or provide a link ? Want to test to see how this works in our environment. Our 1692's have been chunky paperweights ever since last year

    Thanks.
    Glenn Copes
    Have successfully loaded firmware 1.1.0, and it does seem much better than the 1.0 version! :D

    Although, in saying this, i can only get the phone to work with static values so far.
    Values are not being pushed via dhcp, but i believe this is because the particular site im at is missing the TFTPSERVER entry from the dhcp options for this vlan.

    Im going to test at a site which has the correct dhcp options set tomorrow, and I will also test 802.1x.

    *fingers crossed*

    :edit:
    Also looks like the only way to push the firmware is via IIS - can anyone confirm?
    Using the standard avaya fileservers to do the push (as done with the 46xx series phones) does not seem to work.
    John Walshaw
    [Kaman Corporation]
    We utilize IIS as the HTTP server. There are no special IIS settings beyond what we implemetned to support our 96xx phones. We copy the 1692 firmware files into this directory untouched. You may find that the issue you are describing is permissions related. Here is our IIS config:


    • Enable read access, ‘Execute Permissions = scripts only’
    • Disable write access, directory browsing
    • Enable anonymous access
    • Disable integrated windows authentication, basic authentication
    • Remove all document types
    • Create backups directory
      [INDENT]Enable write access
      Set NTFS permissions for IIS anonymous user to have read, write access[/INDENT]
    • For 1616 phones add hex, ld, cfg as supported file extensions



    On a related topic, we are now seeing phones arrive with firmware 1.10. I have a suspiciion of a bug at realease 1.10. It seems that phones with release 1.00 are doing fine with DHCP 242 options. The phones then upgrade to 1.10 and continue to be happy. Phones that ship with 1.10 appear to not pull in any 242 options from DHCP. This leaves us manually configuring the call server IP and file server IP, which was not necassary before. I'll probably test in the lab and if show that this is the case will open a ticket with Avaya.

    The 1692 continues to have poorly implemetned firmware. This phone could be highly robust, like the 96xx are. Avaya could also get Siren 14 / G.722.1C working if they wanted (instead of the fat G.722)... that would transform the 1692 to 1692 calling experience.
    Glenn Copes
    Thanks JJ

    IIS works fine for me to push firmware, we have the settings set correct for mime etc now.

    We used to use the LSP gateways as local fileservers before, this is what i cant make work with the 1692. Not sure if this is intentional or not.?

    In regards to what your saying with DHCP, i did some testing today at a site which has DHCP optios set correctly (all other types of phones work).

    The 1692 still refuses to get IP address even if i assign just the vlan ID by itself - all other settings 0.0.0.0, or if i set the vlan ID, call server and fileserver. This sounds lalot ike the bug your describing with 1.1.0.
    John Walshaw
    [Kaman Corporation]
    BTW An easy method to test a http server is to type the URL into a web browser and append the name of each file. If your browser allows you to download the file, you know that the http server will do the same when a phone does an HTTP GET. If the browser cannot download the file, then you know that phone will not be able to either. This is how I discovered the additional settings needed for 1616 phones. It would be worth testing this method as it would enable you to document the issue you described and open a ticket with Avaya. It would most likely then make it to the next service pack for Aura / Communication manager.

    Re. testing the settings and the suspected DHCP bug, thanks for verifying. It may be possible to reproduce this by doing a "mute RESET #". Sounds like it's time to open another ticket with Avaya to show them this issue. :(
    Glenn Copes
    This is weird.. only just earlier this month (3rd March 2011) i had checked on the Avaya support site for the 1692 firmware, and they had listed 1.1.0 as being available which is what i tested as per my above posts..

    Now, 1.2.0 has been released, but on this link below it states it was released in February 2011. Very strange...

    http://support.avaya.com/css/appmanager/public/support/Downloads/P0656/1.2.x/C20113151216525410_3


    Anyways, i have attempted loading this and this seems for me at least to be better than 1.1.0. Im finding it works better with our 242 DHCP options alot easier, less static options need to be entered. So this is good, we may finally be able to deploy these to users.

    I have now been playing with the 802.1x functionality of these, not sure if anyone else has tried this yet ?
    Ian Grey
    [Provident Financial]
    I have now been playing with the 802.1x functionality of these, not sure if anyone else has tried this yet ?

    We will be trying this out in the next few weeks as having to suppress 802.1X for the spider phones is a bit of a nuisance.
    Jon Pink
    [CWG]
    I have a new 1692 with the 1.2 firmware on it and I am as unimpressed as with the previous versions of firmware. I got it to work finally by hardcoding an IP address on our data VLAN. As with others, when I place directly on Voice VLAN it sits endlessly in 'discover' mode. It doesn't matter whether I use DHCP or hard code address.

    These phones are as poorly programmed as I can imagine. I always hold out hope for the next version of firmware but nothing seems to change.

    Are there any other IP conference phones out there that are any better?

    If so let me know. These phones are just flat out frustrating and I only have 3 of them !!
    Chris Wong
    [Nike]
    I am also facing the same issue, all my 1692 phones can't get an IP address from DHCP server but option 242 has been added, but works fine with the static IP. Can anyone help on this please?

    thanks,
    Chris
    Glenn Copes
    Not sure if you guys have seen or tried this yet, but Avaya released this in May 2011.

    I'm about to try loading this myself to see if it finally resolves the dhcp issues in our environment.

    Link to 1.3.0http://support.avaya.com/css/appmanager/public/support/Downloads/P0656
    Glenn Copes
    OK, have applied 1.3.0 to a 1692 previously running 1.2.0.

    First impressions is this release seems to take a little while longer to be saved to the hardware, but once its applied, all the issues that i had previously are no more!

    DHCP issues: resolved.
    Phone getting stuck on "initializing" screen: resolved.
    General slow booting and crappyness: resolved.

    After i was satisfied that DHCP was being applied properly, i took the phone to another site which has 802.1x applied. Entered in our ID's and passwords, phone rebooted twice, picked up the vlan ID and then worked as its supposed to.

    Highly recommend anyone who is still having issues with this hardware to apply this update.
    Jim Johnson
    [Acme]
    OK, have applied 1.3.0 to a 1692 previously running 1.2.0.
    Any tips on how to get these to update? I've upgraded from a pre-1.0 release to 1.0 before, but I can't get my 1.2.0 phone to upgrade to 1.3.0.
    Glenn Copes
    Any tips on how to get these to update? I've upgraded from a pre-1.0 release to 1.0 before, but I can't get my 1.2.0 phone to upgrade to 1.3.0.


    Hi jimj,

    Steps that worked for me are belw.

    1. I used the Avaya tftpserver util. (iptel_avaya_tftp.exe)
    2. Unzipped the "1692-IPT-H323-R1_3-051611.zip" to the outgoing folder for the tftp server util.
    3. * to program on the phone.
    4. Set the file server on the phone as the IP of your PC running the tftpserver tool.
    5. Set the 1692s fileserver type to TFTP (option 1).
    6. # to save changes and let the phone reboot.

    Hope this helps!
    Glenn Copes
    Hi jimj,

    Steps that worked for me are belw.

    1. I used the Avaya tftpserver util. (iptel_avaya_tftp.exe)
    2. Unzipped the "1692-IPT-H323-R1_3-051611.zip" to the outgoing folder for the tftp server util.
    3. * to program on the phone.
    4. Set the file server on the phone as the IP of your PC running the tftpserver tool.
    5. Set the 1692s fileserver type to TFTP (option 1).
    6. # to save changes and let the phone reboot.

    Hope this helps!

    Forgot to mention, after the phone has downloaded the 1.3.0 update it will reboot twice (i believe from memory). Keep an eye on the tftpserver util screen as it seems to not push the *.bin file on the first pass.

    Basically i left the phone alone, until the update fully completed, and then the phone attempted to pull down our dhcp values.. and it then ended up giving a "No CallSv address" - which is where it stopped.

    Rebooting the phone and then just setting the VLAN ID, allowed the phone to pull down all other values via dhcp.

    At the second site i tested this phone at, i did not need to enter VLAN ID, believe this had something to do the option 242 missing from the vlans at the primary site.

    Hope this helps!
    Jon Pink
    [CWG]
    OK, I finally got my 1692 upgraded from 1.2 to 1.3. The key, as was mentioned earlier, was to use TFTP. Trying to use HTTP flat out failed ! Once I set up a TFTP server and tried it worked fine. I agree that the 1.3 version appears to be more solid than the past versions. After upgrading to 1.3 I switched my file server back to HTTP. Now when I boot the phone it still throws up a 'can't contact boot server' message so I am not sure what to think about that. But otherwise it is functioning fine.
    Inactive Forum User
    Eurica!!!!!

    The following config changes on your IIS 6 web server will finally allow the downloading of version 100 firmware:


    • Go into the properties of the default web site
    • Go to the HTTP headers tab
    • Click MIME types
    • Add entries for cfg, ld (see attached)


    Your IIS http server will now allow these file types to be accessed via HTTP and the phone will finally do a firmware upgrade!!

    The only other pre-req is manually setting the File Server Type = 2 (HTTP) on the phone's '* to program' menu. DHCP can still be used.

    This is the root casue that prevents files from being downloaded. Unfortunately, Avaya have chosen non standard file extensions and have not included any HTTP server re-req info in their release notes. Is MIME type info referenced in any of their documentation?

    I will repeat the tests monitoring the HTTP get/put with firmware 100.

    Interestingly the 1616 phones need a type "hex" added to the MIME types list also as they look for this file during boot. My 1616, which I thought had upgraded fully firmware, has now downlaoded bm32a2_1.hex and saved to flash... this tells me that it was a partially upgraded phone until making this final and important change.

    EDIT: "ld" is the missing file type in order to complete the firmware upgrade. "cfg" is not related to firmware upgrades. It's still unclear what the "cfg" files accomplish and if they casue problems when deployed in an H.323 environment.

    Solved my issue also. Thanks for the leg work on this.

    B
    y a
    [bell]
    received new 1692 w/ f/w file 217bin which is newer than 130bin but website shows latest rls is 140bin. Anyway had issues getting it to register. Eventually had to manually enter correct vlan. once done pulled correct ip etc from dhcp.
    Karl Eisenmenger
    [US Army]
    During an upgrade of approximately 40 1692’s from 1.2 to 1.3. I discovered that about half of them failed to ever acquire a DHCP address after loading the 1.3. They were completely hosed and would never again boot up all the way.
    I discovered the sticker on the bottom gives a Rev level. All of my 1692’s that failed were Rev A, and all the 1692’s that worked are Rev. B.
    I had Avaya really scrambling to get me 20 1692’s overnight. The new sets that came in are Rev C @ 1.3.
    :D
    Andrew Sandoval

    i read in one of your post that you can bypass this error message? do you know how to bypass it? when it tries to start it gets stuck on this message and doesnt do anything else. #RESET doesnt work can you please HELP


    All Times America/New_York


    Copyright © 2014.'The International Avaya User Group. All Rights Reserved

    All material, files, logos and tradarks within this site are properties of their respective organizations.


    Terms of Service - Privacy Policy - Contact