Ok. We are making progress. It APPEARS as though the phone is now communicating with the sipX via FTP. I deleted and recreated one of the remote phones in sipX, changing the line configuration from what it used to be (so I could actually SEE a change from the old configuration). The configuration was indeed updated.
The PROBLEM is that it isn't downgrading the firmware. I uploaded the 3.1.3c file in Devices > Device Files. I setup a new "profile" basically using the 3.1.3c file and 4.2.2 bootrom and just deactivated the 3.2.3 "profile". Ideas? On Thu, Jul 15, 2010 at 3:56 PM, JOLY, ROBERT (ROBERT) <rj...@avaya.com>wrote: > > 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? > > Yes, TFTP does not go across NATs and firewalls unless you have a TFTP ALG > on your router (and few do). This is due to the fact that TFTP uses an > ephemeral port for sending down the file to the client. You will have much > better luck using FTP. > > > > > > > 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#Actiont > > ec <http://www.dd-wrt.com/wiki/index.php/Supported_Devices#Actiontec> > > > > > > > > <http://www.dd-wrt.com/wiki/index.php/Supported_Devices#Action > > tec> 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 > > <http://www.linkedin.com/in/garylukes> > > > > > > > _______________________________________________ > > > sipx-users mailing list > > sipx-users@list.sipfoundry.org > > > List Archive: > > http://list.sipfoundry.org/archive/sipx-users > > <http://list.sipfoundry.org/archive/sipx-users> > > > Unsubscribe: > > http://list.sipfoundry.org/mailman/listinfo/sipx-users > > <http://list.sipfoundry.org/mailman/listinfo/sipx-users> > > > sipXecs IP PBX -- > > http://www.sipfoundry.org/ <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 > > > > > -- 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/
