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/
