you wrote, "Is it just this hard for you?" I'm not sure how to take that.
Anyway, I did as you said and clicked "Send Profiles." The job failed due to timeout, but it must have generated all the files, because on the next reboot, the phone registered - via tftp! I know you think it's easier to use FTP, but I have to work within the resources and limitations I have. Thanks again for your help and insight. BTW, I can dial another extension, but I get no audio. I'll try do dig that out on my own via the book, the wiki and the archives before I bother anyone else. Stiles Tony Graziano wrote: > Go to the phone in sipxconfig and generate (push) profile to the phone. A > reboot of the phone is not necessary. > > Is it just this hard for you? > > Hopefully you don't have a version of firmware earlier than 3.2.1. A 335 is > a difficult phone to deploy remotely with a polycom r.e bug. If I were you > I'd turn off any device files (inactivate) so you aren't mistakenly trying > to push an ealier version. > ============================ > Tony Graziano, Manager > Telephone: 434.984.8430 > Fax: 434.984.8431 > > Email: tgrazi...@myitdepartment.net > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > ----- Original Message ----- > From: sipx-users-boun...@list.sipfoundry.org > <sipx-users-boun...@list.sipfoundry.org> > To: Discussion list for users of sipXecs software > <sipx-users@list.sipfoundry.org> > Sent: Mon Sep 20 13:06:57 2010 > Subject: Re: [sipx-users] SRV records for ftp > > That is very true. > > Interesting development: I pulled down the polycom ip 335 admin guide > and on the top of page 41 (3-5) there is the following note: > > "Setting Option 66 to tftp://192.168.9.10 has the effect of forcing a > TFTP download. Using a TFTP URL (for example, > tftp://provserver.polycom.com) has the same effect." > > So, I manually configed the phone and set the "Server Type" to > "TrivalFTP," and set the "Server Address" to "tftp://24.106.178.178"; > (the WAN), opened the firewall to allow tftp traffic to the sipxecs > subnet, added appropriate NAT policies, rebooted the phone and ... > > I get "Config file error Error is 0x20" and the phone continuously > reboots. On reboot, the phone displays "Updating Config," gets an IP, > displays the error and the process starts all over again. > > I'm assuming this means it actually tried to get a file from the server > and there is either something wrong with the file or no file was found, > but that is just a guess. Based on this assumption, I executed a find > for the MAC.cfg on the server, but nothing was found, which seems > incorrect. > > Am I getting closer or just spinning my wheels? > > Stiles > > > Tony Graziano wrote: > >> You changes the sip password in sipxconfig since the phone loaded its >> profile last. >> ============================ >> Tony Graziano, Manager >> Telephone: 434.984.8430 >> Fax: 434.984.8431 >> >> Email: tgrazi...@myitdepartment.net >> >> LAN/Telephony/Security and Control Systems Helpdesk: >> Telephone: 434.984.8426 >> Fax: 434.984.8427 >> >> Helpdesk Contract Customers: >> http://www.myitdepartment.net/gethelp/ >> >> ----- Original Message ----- >> From: sipx-users-boun...@list.sipfoundry.org >> <sipx-users-boun...@list.sipfoundry.org> >> To: Discussion list for users of sipXecs software >> <sipx-users@list.sipfoundry.org> >> Sent: Mon Sep 20 12:02:33 2010 >> Subject: Re: [sipx-users] SRV records for ftp >> >> The registration request is getting to sipx. I turned the logging level >> to DEBUG, restarted the services and executed following: >> >> tail -f /var/log/sipxpbx/sipXproxy.log | grep "REGISTER sip" | grep >> "1...@datatek-net.com" > regdebug141.log >> >> After the polycom reboot completed, I executed >> >> wc -l regdebug141.log >> >> and received "17 regdebug141.log" as the result. I then executed >> >> grep -i received regdebug141.log | wc -l >> >> with a result of '9'. When I tail /var/log/sipxpbx/sipregistrar.log I >> see the following: >> >> "2010-09-20T15:19:11.048702Z":33020:AUTH:DEBUG:sipx.datatek-net.com:SipRegistrarServer:B6C81B90:SipRegistrar:"SipRegistrarServer::isAuthorized >> fromNameAddr='\"Stiles >> Watson\"<sip:1...@datatek-net.com>;tag=1F8AD21E-973871A1', >> toUri='sip:1...@datatek-net.com', realm='datatek-net.com'" >> "2010-09-20T15:19:11.051052Z":33028:AUTH:ERR:sipx.datatek-net.com:SipRegistrarServer:B6C81B90:SipRegistrar:"Response >> auth hash does not match (bad password?) toUri='sip:1...@datatek-net.com' >> requestUser='141/0004f22d79be' >> requestNonce='473b74442d2dcf443a0823b9dbbdefaa4c977b6e' >> uriParam='sip:datatek-net.com:5060' passTokenDB='6qk50suJ' >> authTypeDB='DIGEST'" >> >> "2010-09-20T15:19:11.052127Z":33030:SIP:DEBUG:sipx.datatek-net.com:SipRegistrarServer:B6C81B90:SipRegistrar:" >> ---------------------------------- >> Sending final response >> SIP/2.0 401 Unauthorized >> From: \"Stiles Watson\" <sip:1...@datatek-net.com>;tag=1F8AD21E-973871A1 >> To: <sip:1...@datatek-net.com>;tag=50CQ8f >> Call-Id: 653dce0e-9a15011-6ecf0...@192.168.16.102 >> Cseq: 2 REGISTER >> Via: SIP/2.0/TCP >> 24.106.178.178:5060;branch=z9hG4bK-XX-131f715siA6jenamQxLO0Tevfg;received=192.168.25.11;rport=54527 >> Via: SIP/2.0/UDP >> 192.168.16.102;branch=z9hG4bK6e5a416f288A684A;received=75.189.229.254;rport=5060 >> Www-Authenticate: Digest realm=\"datatek-net.com\", >> nonce=\"9406c4cb79ee436c0cfd9b2082a412444c977b6f\", qop=\"auth\" >> User-Agent: sipXecs/4.2.1 sipXecs/registry (Linux) >> Content-Length: 0" >> >> "2010-09-20T15:19:11.061815Z":33038:OUTGOING:INFO:sipx.datatek-net.com:SipRegistrarServer:B6C81B90:SipRegistrar:"SipUserAgent::sendTcp >> TCP SIP User Agent sent message: >> ----Local Host:192.168.25.11---- Port: -1---- >> ----Remote Host:192.168.25.11---- Port: 54527---- >> SIP/2.0 401 Unauthorized >> From: \"Stiles Watson\" <sip:1...@datatek-net.com>;tag=1F8AD21E-973871A1 >> To: <sip:1...@datatek-net.com>;tag=50CQ8f >> Call-Id: 653dce0e-9a15011-6ecf0...@192.168.16.102 >> Cseq: 2 REGISTER >> Via: SIP/2.0/TCP >> 24.106.178.178:5060;branch=z9hG4bK-XX-131f715siA6jenamQxLO0Tevfg;received=192.168.25.11;rport=54527 >> Via: SIP/2.0/UDP >> 192.168.16.102;branch=z9hG4bK6e5a416f288A684A;received=75.189.229.254;rport=5060 >> Www-Authenticate: Digest realm=\"datatek-net.com\", >> nonce=\"9406c4cb79ee436c0cfd9b2082a412444c977b6f\", qop=\"auth\" >> User-Agent: sipXecs/4.2.1 sipXecs/registry (Linux) >> Date: Mon, 20 Sep 2010 15:19:11 GMT >> Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, REGISTER, SUBSCRIBE >> Accept-Language: en >> Supported: gruu, path >> Content-Length: 0 >> >> --------------------END--------------------" >> >> I've tripple-checked the SIP pasword and it is correct. So I'm guessing >> "Response auth hash does not match (bad password?)" from the debug >> statement is referring to something else. >> >> Stiles >> >> Tony Graziano wrote: >> >> >>> If it has a valid config file and the remoe firewall has spi and sip alg >>> off >>> and your sonicwall is not getting in thje way, yes. >>> ============================ >>> Tony Graziano, Manager >>> Telephone: 434.984.8430 >>> Fax: 434.984.8431 >>> >>> Email: tgrazi...@myitdepartment.net >>> >>> LAN/Telephony/Security and Control Systems Helpdesk: >>> Telephone: 434.984.8426 >>> Fax: 434.984.8427 >>> >>> Helpdesk Contract Customers: >>> http://www.myitdepartment.net/gethelp/ >>> >>> ----- Original Message ----- >>> From: sipx-users-boun...@list.sipfoundry.org >>> <sipx-users-boun...@list.sipfoundry.org> >>> To: Discussion list for users of sipXecs software >>> <sipx-users@list.sipfoundry.org> >>> Sent: Mon Sep 20 07:50:59 2010 >>> Subject: Re: [sipx-users] SRV records for ftp >>> >>> Still working through the options you've given me, but the Polysom should >>> be able to register remotely without ftp if everything is configed >>> correctly, right? >>> >>> Stiles >>> >>> On Fri, 17 Sep 2010 20:43:24 -0400, Tony Graziano >>> <tgrazi...@myitdepartment.net> wrote: >>> >>> >>> >>>> By the way... the first sentence in this thread is: >>>> "OK Tony, shoot me down:" >>>> >>>> It's actually the IETF and Polycom who did the shooting here... >>>> IETF should write two papers on an RFC. Once for engineers, and one for >>>> everyone else instead of trying to deciper what they mean with loosely >>>> selected verbs. >>>> Polycom (like a lot of hardware manufacturers) should state, this works >>>> for this, that works for that, and not you can't mix and match ip's and >>>> ports, we like it this way... it wouldn't be that hard. >>>> On Fri, Sep 17, 2010 at 7:02 PM, Tony Graziano wrote: >>>> Realize the Aastra is a different client, and "how" the manufacturer >>>> implements a protocol is VERY different from another one... >>>> FTP is the way to do it, and these days PASV FTP is pretty much needed >>>> >>>> >>>> >>> to >>> >>> >>> >>>> do bootrom updates with Polycom. Even in their http/https provisioning >>>> they won't do bootrom and firmware over https, only http. So it's not as >>>> simple as "just make sipx use https", it would have to do both. Add to >>>> that Polycom is constantly changing their config file format, >>>> >>>> >>>> >>> parameters, >>> >>> >>> >>>> arguments, etc. FTP works, so that's what I suggest to do. >>>> Can you get another IP and add it to the firewall (even if just for >>>> ftp)...? >>>> >>>> On Fri, Sep 17, 2010 at 6:26 PM, Stiles Watson wrote: >>>> Thanks, you are a wealth of info! I'll try the several options you've >>>> given me. >>>> >>>> FYI, I had an Aastra 67301i auto provisioning with trixbox CE via TFTP. >>>> The phone made its request to the public IP and all I had to do on the >>>> local firewall was open the port for WAN to trixbox subnet and create >>>> the NAT rules to send the request to the trixbox server. No remote >>>> firewall config had to be done. >>>> >>>> Stiles >>>> >>>> Tony Graziano wrote: >>>> > Crap. That's a loaded question. >>>> > >>>> > It all in the protocol, and ANY nat translation. >>>> > >>>> > TFTP (nothing to do with sipx, its the nature of tftp) must use a >>>> > pseudo random port or your remote firewall must have a way to punch >>>> > through udp in NAT mode, which is not the same as ANY NAT >>>> >>>> >>>> >>> translation, >>> >>> >>> >>>> > which means it is inherently PASV, but the typical tftpd in linux >>>> >>>> >>>> >>> does >>> >>> >>> >>>> > not have the ability to specify PORTS. It's like PASV FTP, where port >>>> > 21 is the control channel, but in vsftpd you specify the ports where >>>> > the requests for data is coming from. It is more likely the remote >>>> > firewall (try putting the phone IP as a DMZ host just to see if tftp >>>> > works). I don't fiddle much with home based routers, they're a pain. >>>> > >>>> > http://www.rfc-editor.org/rfc/rfc3489.txt [3] >>>> > >>>> > It makes me need a drink, and its why I use FTP for remote phones. >>>> > >>>> > There is a way to get that to work, but you must have the required >>>> > items (port translation, and that pattern is full). >>>> > >>>> > >>>> > On Fri, Sep 17, 2010 at 5:55 PM, Stiles Watson > wrote: >>>> > >>>> > Well, not so happy about that. >>>> > >>>> > Thanks for the explanation though. >>>> > >>>> > So ... why can I not use TFTP? >>>> > >>>> > Stiles >>>> > >>>> > Tony Graziano wrote: >>>> >> Er.. Bang? >>>> >> >>>> >> I could assume the FTP NAT/PAT (NAT with port translation) from >>>> >> 21 to 844 would work... >>>> >> >>>> >> PHONE--(grab file at >>>> >> ftp://1.2.3.4:8444 [6])INTERNET 192.168.2.2:21 [7] , >>>> sending it on>>--vsftpd >>>> >> >>>> >> 1. I don't think the polycom is sophisticated enough to do any >>>> >> type of DNS lookup other than hostname or IP for ftp, so the >>>> SRV >>>> >> record is not useful, you're better off removing it. >>>> >> 2. The remote phone must be hardcoded >>>> >> (menu>advanced>servermenu>ftp ftp port BUT the >>>> >> polycom doesn't allow you to change the PORT. >>>> >> >>>> >> If the SRV records do work, you should alter vsftpd to run on >>>> >> that port anyway, but I am doubtful that is functional. >>>> >> >>>> >> >>>> >>>> >>>> >>>> >>> http://www.polycom.com/global/documents/support/setup_maintenance/products/voice/spip_ssip_Admin_Guide_SIP_3_1.pdf >>> >>> >>> >>>> [9] >>>> >> >>>> >> 3-9 and 3-10 pretty much tell me a hostname or IP is all they >>>> >> accept. The protocols are perhaps non-negotiable for >>>> provisioning >>>> >> to alter the port with the exception of the "120" option, which >>>> >> is a string, though the polycom may not handle parsing the >>>> >> ip:port part of it as it has very limited logic at bootup. >>>> >> >>>> >> Don't assume when they say ftps they mean ftp over ssh, its >>>> not, >>>> >> it means ssl is configured and running on your ftp server, but >>>> >> still running on port 21. So you either need to "change" the >>>> NAT >>>> >> on your firewall and see if the PASV config setting work and >>>> the >>>> >> phone provisions remotely, then decide how you want to proceed. >>>> >> >>>> >> Bootrom changes pretty much force a "non-active" FTP server to >>>> be >>>> >> out of the picture (really, in the document link above, go >>>> >> figure), which means you can upgrade firmware and config but >>>> not >>>> >> bootrom after a certain version is loaded. So thanks Doug for >>>> >> pushing on this one. >>>> >> >>>> >> I think Polycom is REAL FUZZY on this, because they don't >>>> >> EXPLICITLY state the following: >>>> >> >>>> >> FTP or FTPS means PORT 21, no exceptions! (etc. for ftfp, http >>>> on >>>> >> port 80 https on 443, etc. >>>> >> PASV FTP requires the following commands to be available on the >>>> >> FTP server (and provide the fracking list!). >>>> >> >>>> >> I am real doubtful you can put in a "120" string and do >>>> >> "ftp://1.2.3.4:8444 [10]", but heck maybe you can and I'm just >>>> too >>>> >> lazy to try? >>>> >> >>>> >> So this means you can test with what you got but rearrange the >>>> >> firewall, push your configs, and then change it back... or get >>>> >> another public IP on your firewall for this... >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> On Fri, Sep 17, 2010 at 5:19 PM, Stiles Watson >>>> >> wrote: >>>> >> >>>> >> OK Tony, shoot me down: >>>> >> >>>> >> I'm attempting to do what you suggested and use FTP >>>> instead >>>> >> of TFTP for >>>> >> remote provisioning the Polycom IP 335. The problem is >>>> that >>>> >> we already >>>> >> use FTP and we can not move our customer facing FTP to >>>> >> another port. I >>>> >> figured I could just configure the phone to use ftp on >>>> >> another port - >>>> >> but i was wrong (at least I could not find an place to do >>>> it). >>>> >> >>>> >> Therefore, my solution: >>>> >> >>>> >> * setup an SRV record to point to the non-standard ftp >>>> port >>>> >> (8444) >>>> >> >>>> >> ** _ftp._tcp.datatek-net.com [13] . >>>> >> 7200 IN SRV 0 0 8444 datatek-net.com [15] >>>> >> . >>>> >> >>>> >> ** this SRV record was created on the primary DNS for our >>>> >> domain and not >>>> >> on the DNS server running on the sipX box as it is behind >>>> NAT. >>>> >> >>>> >> * configured the phone to use FTP and use the SRV url as >>>> the >>>> >> server ( >>>> >> _ftp._tcp.datatek-net.com [17] ) >>>> >> >>>> >> * configured the firewall to allow (8444) traffic from >>>> WAN to >>>> >> the sipX >>>> >> subdomain >>>> >> >>>> >> * created a PAT policy to translate port 8444 coming into >>>> the >>>> >> WAN to >>>> >> port 21 and forwarded it to the sipX server. >>>> >> >>>> >> I also configed vsftp.conf via your xx-8904 ticket as you >>>> >> suggested. >>>> >> >>>> >> But ... it still does not work. >>>> >> >>>> >> By the way, I bought the e-book yesterday and am finding >>>> it >>>> >> very helpful. >>>> >> >>>> >> Stiles >>>> >> _______________________________________________ >>>> >> sipx-users mailing list >>>> >> sipx-users@list.sipfoundry.org [19] >>>> >> >>>> >> List Archive: >>>> http://list.sipfoundry.org/archive/sipx-users/ [21] >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> ====================== >>>> >> Tony Graziano, Manager >>>> >> Telephone: 434.984.8430 >>>> >>>> >>>> >>> begin_of_the_skype_highlighting 434.984.8430 >>> end_of_the_skype_highlighting >>> >>> >>> >>>> >> sip: tgrazi...@voice.myitdepartment.net [22] >>>> >> >>>> >> Fax: 434.984.8431 >>>> >> >>>> >> Email: tgrazi...@myitdepartment.net [24] >>>> >> >>>> >> >>>> >> LAN/Telephony/Security and Control Systems Helpdesk: >>>> >> Telephone: 434.984.8426 >>>> >> sip: helpd...@voice.myitdepartment.net [26] >>>> >> >>>> >> Fax: 434.984.8427 >>>> >> >>>> >> Helpdesk Contract Customers: >>>> >> http://www.myitdepartment.net/gethelp/ [28] >>>> >> >>>> >> Why do mathematicians always confuse Halloween and Christmas? >>>> >> Because 31 Oct = 25 Dec. >>>> >> >>>> >> >>>> ------------------------------------------------------------------------ >>>> >> _______________________________________________ sipx-users >>>> >> mailing list sipx-users@list.sipfoundry.org [29] >>>> >> List Archive: >>>> >> http://list.sipfoundry.org/archive/sipx-users/ [31] >>>> > >>>> > >>>> > _______________________________________________ >>>> > sipx-users mailing list >>>> > sipx-users@list.sipfoundry.org [32] >>>> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>> [34] >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > ====================== >>>> > Tony Graziano, Manager >>>> > Telephone: 434.984.8430 >>>> > sip: tgrazi...@voice.myitdepartment.net [35] >>>> > >>>> > Fax: 434.984.8431 >>>> > >>>> > Email: tgrazi...@myitdepartment.net [37] >>>> > >>>> > LAN/Telephony/Security and Control Systems Helpdesk: >>>> > Telephone: 434.984.8426 >>>> > sip: helpd...@voice.myitdepartment.net [39] >>>> > >>>> > Fax: 434.984.8427 >>>> > >>>> > Helpdesk Contract Customers: >>>> > http://www.myitdepartment.net/gethelp/ [41] >>>> > >>>> > Why do mathematicians always confuse Halloween and Christmas? >>>> > Because 31 Oct = 25 Dec. >>>> > >>>> > >>>> ------------------------------------------------------------------------ >>>> > >>>> > _______________________________________________ >>>> > sipx-users mailing list >>>> > sipx-users@list.sipfoundry.org [42] >>>> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ [43] >>>> >>>> _______________________________________________ >>>> sipx-users mailing list >>>> sipx-users@list.sipfoundry.org [44] >>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ [45] >>>> >>>> -- >>>> ====================== >>>> Tony Graziano, Manager >>>> Telephone: 434.984.8430 >>>> sip: tgrazi...@voice.myitdepartment.net [46] >>>> Fax: 434.984.8431 >>>> >>>> Email: tgrazi...@myitdepartment.net [47] >>>> >>>> LAN/Telephony/Security and Control Systems Helpdesk: >>>> Telephone: 434.984.8426 >>>> sip: helpd...@voice.myitdepartment.net [48] >>>> Fax: 434.984.8427 >>>> >>>> Helpdesk Contract Customers: >>>> http://www.myitdepartment.net/gethelp/ [49] >>>> >>>> Why do mathematicians always confuse Halloween and Christmas? >>>> Because 31 Oct = 25 Dec. >>>> >>>> >>>> >>> _______________________________________________ >>> sipx-users mailing list >>> sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> _______________________________________________ >>> sipx-users mailing list >>> sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >>> >>> >>> >>> >> _______________________________________________ >> sipx-users mailing list >> sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> _______________________________________________ >> sipx-users mailing list >> sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> >> >> > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
