Ok. So. I'm trying to remotely re-provision the phone and downgrade the firmware. I figured i'd try TFTP first since I know that works in the local office. So I forwarded port 69 on the local router to the internal IP of my sipX. Went into the network setup menu on the phone and defined " myhostname.no-ip.org" as the boot server, using TFTP. I rebooted and I'm getting an error that the phone can't connect to the boot server. Any ideas?
On Thu, Jul 15, 2010 at 6:39 AM, Tony Graziano <tgrazi...@myitdepartment.net > wrote: > I may have spoke too soon... > > I see you can load dd-wrt on the actiontek... > > http://www.dd-wrt.com/wiki/index.php/Supported_Devices#Actiontec > > <http://www.dd-wrt.com/wiki/index.php/Supported_Devices#Actiontec>Question > is what revision and is it in the supported devices list or on the HCL list, > only rev a,b,c,d are supported it seems. > > On Thu, Jul 15, 2010 at 5:58 AM, Tony Graziano < > tgrazi...@myitdepartment.net> wrote: > >> You might find your internal firewall may have an issue as well passing >> audio if it cannot do symmetrical NAT (which I doubt). >> >> So once you get DNS setup where the phones will register you should try >> making a call and if you get no (or one-way audio), you should stop and >> address the firewall piece. >> >> If it were me (and it is not), I would see if I could set the verizon >> modem to "bridged" mode and put a compatible firewall in. I say this because >> in looking through the fios devices of that model, I see nothing which >> encourages me that this is something that has the guts to work in the way >> that is needed, but is fine for a remote site. >> >> On Thu, Jul 15, 2010 at 3:55 AM, Paul Scheepens <pscheep...@epo.org>wrote: >> >>> Gary Luca <garyluc...@gmail.com> wrote on 15-07-2010 05:02:40: >>> >>> > Ok. So I just got a whole TON of replies with questions to answer. >>> Here goes: >>> > >>> > Nathaniel... >>> > >>> > DNS/DHCP at the remote site are handled by the Westell ADSL2 modem. >>> > It deals out just IP, Subnet mask, gateway (itself) and DNS (also >>> > itself). DNS relays to what I imagine are Verizon DNS servers. The >>> > relavent DNS records on the local network (in Microsoft DNS Server) >>> > are as follows: >>> > >>> > spadafora4senate.com >>> > mal-pbx (A) 172.16.17.45 >>> > spadafora4senate.com (NAPTR) [2][0][S][SIP+D2U]<Reg Exp>[_sip._ >>> > udp.spadafora4senate.com.] >>> > spadafora4senate.com (NAPTR) [2][0][S][SIP+D2T]<Reg Exp>[_sip._ >>> > tcp.spadafora4senate.com.] >>> >>> As far as I know you can skip the NAPTR's, I have been running without >>> them for years. >>> >>> > >>> > _tcp.spadafora4senate.com >>> > _sip (SRV) [200][1][5060] mal-pbx.spadafora4senate.com. >>> > _sips (SRV) [300][1][5060] mal-pbx.spadafora4senate.com. >>> > >>> > _udp.spadafora4senate.com >>> > _sip (SRV) [100][1][5060] mal-pbx.spadafora4senate.com. >>> > >>> >>> These are the DNS records you use on the central site, that's why your >>> Polycoms work locally. >>> You need something similar on the remote site, that's what's missing. >>> >>> > Doug... >>> > >>> > Thank you for the link regarding FTP. Do you know of any place >>> > where I can find detailed instructions on how precisely to configure >>> > sipX for whatever it needs in order for FTP to work for phone >>> > provisioning? On the local network I use TFTP, which I don't mind >>> > because it is a secure network. For the REMOTES i'd rather use FTP >>> > as it incorporates authentication. >>> > >>> > Tony... >>> > >>> > I actually thought it WAS a DNS issue for a while. I looked through >>> > the wiki and everything I could find about DNS considerations for >>> > sipX and nothing mentioned anything about external DNS (that I could >>> > see). So, being fairly new to the SIP world, I assumed the only >>> > resolution that had to be done by the remote phone was in regards to >>> > the Outgoing Proxy. I figured it just contacted the Outgoing Proxy >>> > and that acted as the middle man for everything, not requiring the >>> > phone to have to do any other DNS resolution or anything. The >>> > proxy, being on the local network, would resolve everything to the >>> > local DNS and just make everything work for the remote user. It >>> > seemed to make sense, but my limited knowledge of the inner workings >>> > of the relationship between the remote, the proxy, and the registrar >>> > left me without a DEFINITE answer. >>> > >>> > So at that point, with the phones just NOT registering at all, it >>> > was clear that it could be ANYTHING. My sipX config could be wrong. >>> > I could have screwed something up with the NAT traversal features. >>> > It could have been a DNS issue. It could have been a phone issue. >>> > So I had to narrow it down. That's when I installed x-lite. And >>> > within like a MINUTE, I had it connected to sipX and able to make >>> > and receive calls. There was NO VPN involved or anything. Just >>> > straight over the internet through a NAT on both ends. Here are the >>> > settings I used: >>> > >>> > General >>> > User ID: x703 >>> > Domain: spadafora4senate.com >>> > Password: ********* >>> > Display name: Gary Luca >>> > Authorization name: [blank] >>> > >>> > Register with domain and receive calls: [checked] >>> > Send outbound via: Proxy - Address: myhostname.no-ip.org >>> >>> Get x-lite working without "Send outbound via Proxy". >>> By enabling "Send outbound via Proxy" x-lite will register via the A >>> record of myhostname.no-ip.org. >>> If "Send outbound via Proxy" is disabled x-lite will try to resolve the >>> SRV records for spadafora4senate.com (or was that spada4a4senate.com ;-) >>> This is also the method the Polycom's will use. >>> >>> Now you need to create the corresponding SRV records somewhere so that >>> x-lite and polycoms on the remote site can register via SRV records: >>> >>> _tcp.spadafora4senate.com >>> _sip (SRV) [200][1][5060] myhostname.no-ip.org >>> _sips (SRV) [300][1][5060] myhostname.no-ip.org >>> >>> _udp.spadafora4senate.com >>> _sip (SRV) [100][1][5060] myhostname.no-ip.org >>> >>> This can be done by defining the SRV records on your internet dns-server >>> (ISP) >>> or setting up a DNS at the remote site or ... I don't know your setup >>> enough to give the best advise. >>> >>> > Dial plan: #1\a\a.T;match=1;prestrip=2; >>> > >>> > Topology >>> > IP Address: Use local IP address >>> > STUN Server: Discover server >>> > Enable ICE: [unchecked] >>> > >>> > Manually specify range: [unchecked] >>> >>> I think this is the port range (don't have x-lite running), normally the >>> port range >>> is limited to keep the firewall rules simple and not too open. >>> It is normally limited to ports 30000-31000, a smaller range is also >>> possible. >>> >>> > >>> > Presence >>> > Mode: Peer-to-peer >>> > Poll time: 300 >>> > Refresh interval: 3600 >>> > >>> > Transport >>> > Signaling transport: UDP >>> > >>> > Advanced >>> > Reregister every: 3600 seconds >>> > Minimum time: 20 seconds >>> > Maximum time: 1800 seconds >>> > >>> > Enable session timers: [unchecked] >>> > >>> > Send SIP keep-alives: [checked] >>> > Use rport: [checked] >>> > Send outgoing request directly to target: [checked] >>> > >>> > So if what I assuming about the proxy being the middle man is wrong >>> > and what you are saying about the remote needing to resolve the SRVs >>> > itself is correct, then I have absolutely NO idea why x-lite is >>> > working. But it is. If you want to email me directly (outside of >>> > the list), I'll even set you up with a test user on my system so you >>> > can configure x-lite or any other manually configured phone (soft or >>> > hard) and evaluate the results. >>> > >>> > Dale... >>> > >>> > The phone doesn't list in the Registrations page. On the phone >>> > interface, the little "phone" icon next to each of the two line >>> > buttons is "hollow" indicating that the line did not register (not >>> > sure how familiar you are with the Polycom display). Calls to the >>> > phone fail to make it ring. >>> > >>> > Thank you all. Let me know if I can clarify anything further. I >>> > look forward to your thoughts >>> > >>> > -G >>> > >>> > >>> > >>> > -- >>> > Gary J. Luca Jr. >>> > >>> > 781-333-8087 >>> > http://www.linkedin.com/in/garylukes >>> >>> > _______________________________________________ >>> > sipx-users mailing list sipx-users@list.sipfoundry.org >>> > List Archive: http://list.sipfoundry.org/archive/sipx-users >>> > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >>> > sipXecs IP PBX -- http://www.sipfoundry.org/ >>> >>> _______________________________________________ >>> sipx-users mailing list sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users >>> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >>> sipXecs IP PBX -- http://www.sipfoundry.org/ >>> >> >> >> >> -- >> ====================== >> Tony Graziano, Manager >> Telephone: 434.984.8430 >> sip: tgrazi...@voice.myitdepartment.net >> Fax: 434.984.8431 >> >> Email: tgrazi...@myitdepartment.net >> >> LAN/Telephony/Security and Control Systems Helpdesk: >> Telephone: 434.984.8426 >> sip: helpd...@voice.myitdepartment.net >> Fax: 434.984.8427 >> >> Helpdesk Contract Customers: >> http://www.myitdepartment.net/gethelp/ >> >> Why do mathematicians always confuse Halloween and Christmas? >> Because 31 Oct = 25 Dec. >> >> > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: tgrazi...@voice.myitdepartment.net > Fax: 434.984.8431 > > Email: tgrazi...@myitdepartment.net > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: helpd...@voice.myitdepartment.net > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > Why do mathematicians always confuse Halloween and Christmas? > Because 31 Oct = 25 Dec. > > -- Gary J. Luca Jr. 781-333-8087 http://www.linkedin.com/in/garylukes
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
