Agreed. AC Does not make it easy as they prefer a device that is out of the box to configure automatically. I find you need to default the box in order to use their provisioning method. That is probably why it is not used by everyone.
===================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.326.5325 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/ tony-graziano/14/4a6/7a4 On Apr 15, 2011 12:39 PM, "Michael Picher" <[email protected]> wrote: > the bootp here is the big thing... i think the next-server option sets it > up properly and then you need a static entry in dhcp for the gw.... > > personally I don't like to have my gateways auto configure... i download > the .ini from the openuc/sipxecs gui and upload to acodes gui. > > Mike > > On Mon, Apr 11, 2011 at 3:23 PM, Black, Dave (CallPoint Canada) < > [email protected]> wrote: > >> I have to agree with Tony... The major stumbling block for me in getting >> auto provisioning to work is that the audiocodes does not wait long enough >> for the bootp reply messages before moving on to using factory default or >> programmed settings. In most cases I have to disable STP (RSTP) on the >> switch port that the audio codes is connected so bootp packets are forward >> right away after the link is up. You can test this by using a cheep hub >> device in between audiocodes and network switch, pressing and holding the >> reset button on the audiocodes for 20 or more sections and watch the traffic >> on the switch.. >> >> Dave B. >> >> >> -----Original Message----- >> From: [email protected] [mailto: >> [email protected]] On Behalf Of Tony Graziano >> Sent: April-05-11 6:19 AM >> To: Discussion list for users of sipXecs software >> Subject: Re: [sipx-users] AC MP-114 FXO auto provisioning problem >> >> I would tend to disagree about autoprovisioning not working. I find >> the autoprovisioning feature a little more involved to setup than a >> handset, but it does work. It is important to know that the gateway >> should be left at factory defaults and the proper sipx bootp configs >> are in place prior to booting the device on the network and that the >> gateway has been created and the profile pushed. The entire >> environment "should" be prepared before connecting the device to the >> network to ensure a proper auto provisioning environment. I have found >> it just doesn't act like you expect if the device has been manually >> configured is all. You also need to make sure the cmp file exists in >> tftp whether the device has it or not. In other words, there should be >> no reason for the device to "stop" with an error that it can't find >> either the firmware or the config file either.... >> >> That being said, I think audiocodes could make the device boot easier >> (no firmware required on tftp in order to grab the config file), but >> that's not really the topic of this discussion... >> >> Once you touch the gateway manually, it becomes more difficult to >> ensure the auto-provisioning works properly, and why once you get it >> out of the box and manually set the IP you don't "want" to change >> anything if it is working anyway. For those who don't care, the >> "upload" to the device is probably sufficient. >> >> Please reference the wiki article on auto-provisioning: >> >> http://wiki.sipfoundry.org/display/sipXecs/Configuring+AudioCodes+Gateways >> >> >> This is the crucial piece: >> >> BootP server >> >> AudioCodes gateway require that your BootP server returns the >> following parameters: >> >> IP Address of the gateway >> Address of TFTP server >> Name of the firmare file >> Name of the configuration file generated by sipXconfig >> Most DHCP servers support BootP: refer to you DHCP server manual on >> how to configure that. If you use dhcpd server, instructions are >> below. >> >> BootP for dhcpd server >> dhcpd is configured by editing /etc/dhcpd.conf file. You need to add >> the following lines to your file: >> >> File: /etc/dhcpd.conf >> >> group { >> next-server sipx.example.org; # TFTP server >> >> >> # you need one host section per each gateway you are deploying >> host ac114fxo {hardware ethernet 00:90:8F:01:23:45; >> fixed-address 10.10.1.200; >> filename "MP118_SIP_F5.00A.036.003.cmp;00908F012345.ini"; # .ini >> file name matches please note how MAC address!} >> } >> >> } >> next-server specifies the FQDN of the TFTP server, it has to be the >> name of the machine on which sipXconfig is running since it will >> contain both firmware (.cmp) and configuration (.ini) file. >> The MAC address of the gateway has to be specified in hardware >> ethernet line. The same address is used to create the .ini file name >> specified in filename line. >> host name is not used by sipXconfig at the moment but it probably >> makes sense to use the same name in sipXconfig UI. >> >> Tony >> >> >> On Tue, Apr 5, 2011 at 5:50 AM, George Niculae <[email protected]> wrote: >> > On Tue, Apr 5, 2011 at 12:42 PM, Todd R. Hodgen <[email protected]> >> wrote: >> >> I think you have a misunderstanding on the configuration of the >> Audiocodes >> >> devices. They are not auto provisioning. They are managed, in that >> they >> >> have a template that has been prepared for them. However, you have to >> move >> >> the INI file that is created by that template to the device yourself, as >> it >> >> appears you are now doing. >> >> >> >> I've had a similar problems with some trunks not disconnecting, which I >> >> could not correct in the configurations that are created by sipXecs. >> >> >> >> There is a ton of optional configurations in the Audiocodes that is >> accessed >> >> via another web interface on the units that is hidden. In there is a >> >> configuration for adjusting the voltage level for detection. I've had >> to >> >> play with it at times to get disconnect to work correctly. >> Unfortunately, I >> >> don't have my notes on that with me at this time, but your Distributor >> >> Support can probably get you the details. Look for a parameter for >> Current >> >> Level. >> >> >> > >> > Looks similar with what QA team is experiencing: >> > http://track.sipfoundry.org/browse/XX-9503 >> > >> > Any suggestion highly appreciated, will post back if we find the >> > solution otherwise. >> > >> > Thanks, >> > George >> > _______________________________________________ >> > sipx-users mailing list >> > [email protected] >> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > > > > -- > There are 10 kinds of people in this world, those who understand binary and > those who don't. > > [email protected] > blog: http://www.sipxecs.info > call: sip:[email protected]
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
