Sara_Donald Posted January 28, 2008 Report Share Posted January 28, 2008 I looked in the logs and found that I have a UDP binding error and RTP error. I allow all of the associated ports outgoing but I do not allow anything back in as I am very security concious. I am using a Billion NAT Router with Firewall enabled and have set all of the associated port in the packet scheduler. I did try allowing DMZ for the computer hosting the pbx but it didnt make a difference, probably because the firewall does not allow incoming connections. Here are the log messages, what do they mean and how do I overcome this situation? [0] 20080128185056: UDP: bind() to port 61584 failed [0] 20080128185112: UDP: bind() to port 61360 failed [5] 20080128185244: BYE Response: Terminate 3c271250d983-xdwq0s2qoe0s [5] 20080128185256: RTP Timeout on 3c2712b62ee7-o2fv21f428lm#a3a998c80b [3] 20080128185256: Via is empty, cannot send reply Kindest Regards, Sara Donald. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 28, 2008 Report Share Posted January 28, 2008 I am very security concious. To get SIP/UDP working as well as it can, you do have to accept a certain amount of risk. Controlling the Risk is the secret. Should we assume that you are trying to register remote phones? setup and SIP trunk, or all the above? What platform are you deploying this on? Win,Linux, or CS410 Do you have the ability to add or publish a public IP directly to the PBX? Are remote phones behind NAT firewalls too? Quote Link to comment Share on other sites More sharing options...
Sara_Donald Posted January 29, 2008 Author Report Share Posted January 29, 2008 Yes, I have several Snom 370's on a private network which uses a PC with two NICs. The private lan is 192.168.0.1, the public lan is 192.168.1.1 which uses VPN and is attached to the billion adsl router which connects to the internet. This router has nat and packet scheduling firewall enabled. 192.168.1.1 uses internet connection sharing to connect all PCs and IP Phones via a switch. 192.168.1.1 has the windows firewall enabled. All ports on the switch use seperate untagged VLANs. I use windows Vista on all PCs. The pbx uses a sip trunk for outgoing calls. The problem is that the phones are not able to get a ringing tone, just scrambled gaga until the call is answered on the other side (this doesnt happen on internal calls). I have tried ringing in via a mobile and sometimes the ringtone is heard but other times there is silence until someone picks up the ip phone. It is obviously a NAT issue and I have turned off the firewalls and placed the public lan 192.168.1.1 into DMZ but it made no difference, the scrambling sound still occurred. Kindest Regards, Sara Donald. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 29, 2008 Report Share Posted January 29, 2008 [5] 20080128185256: RTP Timeout on 3c2712b62ee7-o2fv21f428lm#a3a998c80b[3] 20080128185256: Via is empty, cannot send reply This is serious. RTP timeout usually means one-way audio. The second header is even more remarkable, there is obviously something completely strange going on on the SIP port. At least it does not look like a SIP packet what is arriving on the SIP port. There must be something very strange in your setup... Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 29, 2008 Report Share Posted January 29, 2008 This is serious. RTP timeout usually means one-way audio. Where to start? Let me assume something again. Your Billion ADLS Router has a dynamic single IP address and it's used for WEB Surfing too. You didn't mention the model number Billion Router. Is your ADSL router capable of running in Bridge Mode? IE passing the negotiated IP address to an attached device? Diagnosing any trouble requires that you ask questions that you can legitimately answer. Yes, No, better, Worse and you use these questions my making changes in the hopes that you eliminate 50% of the problem and continue the process on the bad half until you isolate the real problem. So, given the theory of successive aproximative diagnosis, I'd start by eliminating the VPN. Billion lists states they have an H.323 default setting on at least one model router, I'd update the firmware, (send Billion tech suport if the router directly supports a SIP server behind the firewall) They may have a unreleased firmware.) I can't speak for Vista being a known working platform, but I know XP, Server2003, and Linux are all Ok... Does this all work behind the firewall? From what I see the PBX has dual NICs dual IPs', from our experience this means it can have only 1 gateway, 0.1 the Billion Gateway. Why not eliminate the dual NICS and simply VPN the 0.x LAN to the remote sites. That's kind of how the VPN technology began...Why introduce yet another layer (YAL) Eliminating the VPN by doing a port forward of 5060 to the PBX through the Firewall, would be a good test..... This could be a Vista Multihomed routing problem too... No specific advise, hopefully a nugget or two helps in the process... Quote Link to comment Share on other sites More sharing options...
Sara_Donald Posted January 29, 2008 Author Report Share Posted January 29, 2008 I think you may be right about vista and its routing, you only have to look at Microsoft who built the latest SP1 for Vista which puts text on the bottom of your screen saying you have a valuation version even though you have a fully activated RTM. I did try XP and cant say I noticed the scrambling sound. I think I have to go back to the beginning and start without the vpn and forward port 5060 to the pbx machine without the packet scheduler enabled and only using NAT on the router and see if that fixes the problem. Then go back to the vpn and try the same thing by forwarding port 1701 and 5060. If it works on the pbx machine with and without the vpn then it was the router not setup right, if it doesnt then it will definately be a Vista routing issue. Thank you for you advice so far. Kindest Regards, Sara Donald. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 29, 2008 Report Share Posted January 29, 2008 Thank you for you advice so far.Kindest Regards, Sara Donald. Anything that you learn, please post in the best practices for others to learn. I've posted some things we've learned to make XP a good platform. If you're successful with Vista, please advise for all to learn. Cheers, Quote Link to comment Share on other sites More sharing options...
Sara_Donald Posted January 30, 2008 Author Report Share Posted January 30, 2008 Anything that you learn, please post in the best practices for others to learn. I've posted some things we've learned to make XP a good platform. If you're successful with Vista, please advise for all to learn. Cheers, Well here is the answer: There is nothing wrong with windows routing as I tried it with Bria software, I had port forward enabled on port 5060 and it rang normally. Snom IP Phones are the problem by not allowing the phone to route through nat properly when there is more than one IP. I even turned off the firewall and allowed all traffic through and it still didnt work. but if I connect the Snom to the router directly and use the VoIP providers details then it works brilliantly. The Snom will call out behind the firewall and Nat with scrambling sounds instead of a normal ringtone but calls when asnswered are clear and both ways. Snom really need to address this issue as if it cannot work with multiple IPs and Nat then what use is it. I know have to test Snom with STUN but I cannot see it working if it cannot get past the IP issues. Kindest Regards, Sara Donald. Quote Link to comment Share on other sites More sharing options...
brandywinetech.com Posted January 30, 2008 Report Share Posted January 30, 2008 the Snom phones aren't your issue, any phone will act the same way . Routing is routing is routing, albeit windows or Linux or XP or Vista , if you have dual NIC's be sure only the WAN side has a gateway, the inside should be without a routable gateway and no matter what you do, the NAT wil be an issue, opening ports has nothing to do with NAT only on the firewall , the PBX has a SBC session Border controller for resolving NAT issues,, (so stun is not an issue) but if both sides are natted that will be an issue for you having a 192.168.x.x pricate IP on both sides of the PBX is the issue .. yori Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 30, 2008 Report Share Posted January 30, 2008 Agreed on all points with The Monkey. Gee I need a great picture, I'm thinking a Horse Shoe. Something Colt Like. Quote Link to comment Share on other sites More sharing options...
Sara_Donald Posted January 30, 2008 Author Report Share Posted January 30, 2008 Port forwarding works with software phones behind the same network NAT, using the same IP address setup. All software phones work without having the scrambled ring tone. The Snom phones do not work properly behind the setup I have. I setup a VoIP ATA behind the NAT and address setup and it works fine with port forwarding to 192.168.1.1. The only thing I can think of is that if pbxnsip is routing all ip addresses including the vpn then that could cause problems. IP Addresses: 127.0.0.1 [::1] 192.168.1.1 [fe80::51cf:7cec:7066:16fc] [fe80::5efe:c0a8:101] 192.168.0.1 [fe80::f03d:fe22:48ef:f8ab] [fe80::5efe:c0a8:1] 192.168.14.38 [fe80::5efe:c0a8:e26] 192.168.14.38 [fe80::5efe:c0a8:e26] is the VPN. Kindest Regards, Sara Donald. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 30, 2008 Report Share Posted January 30, 2008 Port forwarding works with software phones behind the same network NAT, using the same IP address setup. All software phones work without having the scrambled ring tone. The Snom phones do not work properly behind the setup I have. I setup a VoIP ATA behind the NAT and address setup and it works fine with port forwarding to 192.168.1.1. The only thing I can think of is that if pbxnsip is routing all ip addresses including the vpn then that could cause problems.Sara Donald. Why the VPN? (port forwarding with a VPN wouldn't be necessary) If Softphone on a remote PC behind a NAT firewall works but a Snom (320? 360?) fails to work properly behind the same NAT firewall with no other changes. Then consider... What version firmware are you using on the SNOM phone? V7.x is available Is the NAT firewall handing out IP addresses via DHCP to both the PC and the SNOM Time for some informative log or packet captures. Are you still using dual NICs on the server? Quote Link to comment Share on other sites More sharing options...
Sara_Donald Posted January 30, 2008 Author Report Share Posted January 30, 2008 True. I still have two NICs and I did a pcap trace on the Snom 370 phone which uses firmware 7.1.30 and noticed that the phone was using UDP instead of TCP even though I have outgoing proxy set as :5061;tls. I also noticed another IP address when trying to negotiate the call, the IP address is from another network when I used to use the phone on Satellite. This problem would be a software problem or memory problem. I think snom have far more issues relating to tls than any other phone. I have tried to sort out tls with them previously but it fell on deaf ears. The only thing I can do is reset the phones to factory default and start over. I will also try the PC without two NICs and connect via the network from the router and see if that makes a difference. Kindest Regards, Sara Donald. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 30, 2008 Report Share Posted January 30, 2008 I also noticed another IP address only thing I can do is reset the phones to factory default and start over. With 30+ years in this Industry, resetting a device to factory defaults early in the diagnosis process is a lesson we all learn. It took a few hard knocks to master that one. Remember that lesson forever. It once cost me an entire weekend once. Circa 1988. DUH. I learned long ago that I prefer to risk finding a bug in the latest firmware, as opposed to having a lingering problem, and the fix was to apply the latest firmware. Clients can accept the fact that you went the latest in their best interest, they don't tolerant having problems because you choice not, or did not apply the latest firmware. You can't explain away that choice to an unhappy client. Cheers Quote Link to comment Share on other sites More sharing options...
Sara_Donald Posted January 31, 2008 Author Report Share Posted January 31, 2008 Proof that the Snom Phones keep things in memory which causes problems later when you change routers. I tested the phones on a d-link router once and used a satellite connection and connected to the snom admin via an ip address of 192.168.5.5. I no longer use this network nor do I use the d-link router (not in production). It used UDP previously and now even after I have set TLS it doesnt do what its supposed to. I noticed in my scan of the 192.168.0.1 network that Snom has a checksum error: 590 71.323695 192.168.0.1 192.168.0.82 UDP Source port: 49920 Destination port: 56426 [uDP CHECKSUM INCORRECT] Here is a pcap from the phone which has been edited but you'll get the idea of what it's doing. 1 0.000000000 192.168.0.1 192.168.0.154 UDP Source port: 50198 Destination port: 53576 to 53 0.530881000 192.168.0.1 192.168.0.154 UDP Source port: 50198 Destination port: 53576 54 0.534094000 192.168.0.154 192.168.5.5 TCP 1028 > http [sYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=14803 TSER=0 WS=0 55 0.538629000 192.168.0.154 192.168.0.1 UDP Source port: 53576 Destination port: 50198 to 86 0.843667000 192.168.0.1 192.168.0.154 UDP Source port: 50198 Destination port: 53576 87 0.849741000 192.168.0.154 192.168.0.1 TCP https > 50144 [FIN, ACK] Seq=1 Ack=1 Win=11040 Len=0 88 0.850789000 192.168.0.1 192.168.0.154 TCP 50144 > https [ACK] Seq=1 Ack=2 Win=16326 Len=0 89 0.858153000 192.168.0.154 192.168.0.1 UDP Source port: 53576 Destination port: 50198 to 319 4.138182000 192.168.0.154 192.168.0.1 UDP Source port: 53576 Destination port: 50198 320 4.150070000 192.168.0.154 192.168.0.1 TLSv1 Application Data 321 4.158116000 192.168.0.154 192.168.0.1 UDP Source port: 53576 Destination port: 50198 322 4.165976000 192.168.0.1 192.168.0.154 TLSv1 Application Data 323 4.167510000 192.168.0.154 192.168.0.1 TCP solid-mux > sip-tls [ACK] Seq=788 Ack=434 Win=10967 Len=0 TSV=15166 TSER=1881341 324 4.170829000 192.168.0.1 192.168.0.154 UDP Source port: 50198 Destination port: 53576 to 330 4.247156000 192.168.0.1 192.168.0.154 UDP Source port: 50198 Destination port: 53576 331 4.250827000 192.168.0.154 192.168.0.1 TLSv1 Application Data 332 4.258875000 192.168.0.154 192.168.0.1 UDP Source port: 53576 Destination port: 50198 333 4.264652000 192.168.0.1 192.168.0.154 TLSv1 Application Data 334 4.265884000 192.168.0.154 192.168.0.1 TCP solid-mux > sip-tls [ACK] Seq=1294 Ack=727 Win=10967 Len=0 TSV=15176 TSER=1881350 335 4.278123000 192.168.0.154 192.168.0.1 UDP Source port: 53576 Destination port: 50198 to 708 9.258513000 192.168.0.154 192.168.0.1 UDP Source port: 53576 Destination port: 50198 etc. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted January 31, 2008 Report Share Posted January 31, 2008 Proof that the Snom Phones keep things in memory which causes problems later when you change routers. Opps, I thought you did a settings reset.... This is either old news or you haven't done a firmware factory reset on the phone. IMHO, you designed and deployed a system in a most complex way and you are now going back and trying to make it work. Often times, and in most cases, and especially easy with PBXnSIP to simply start anew and do it over. Don't make it harder than it has to be. For some reason I've lost my Einstein Quote in my Signature,,, Make Everything as simple as possible, but no simpler. Drop all the security stuff as it really does nothing but complicate everything, I severely question Vista as a choice.. Build immediate redundancy and disaster recovery (RAID mirrored drives, either in software (XP Does it with a HACK), or in Hardware, we exclusively use 3WARE. Publish your PBXnSIP IP directly to the NET (use ingress IP filters to limit remote IP's that can register) implement SNMP / TRAPS, FLOW of some other tool on every switch port connection, pbxnsip, plus any firewalls and routers and monitor the system for anomolies.... I feel you're chasing ghosts on the SNOM issues. We have far to many deployed to suddenly discover a problem exists. Our busiest deployment for PBXnSIP using SNOMS had 681 calls today. and that's about a daily average for the last year. Simplify your installation but take the recommended steps to mitigate the risks but prepare for worst. cheers Quote Link to comment Share on other sites More sharing options...
brandywinetech.com Posted January 31, 2008 Report Share Posted January 31, 2008 The UDP ports in your trace are RTP and not the SIP signalling , you are using TLS/TCP for your SIP and yet still using UDP for actual audio, which is your problem , I find it odd you believe Snom has TLS issues when they were one of the first adopters ... I would utilize your VPN to get rid of the remote natting, that would solve the issue right there .. and be double encrypted , yori Quote Link to comment Share on other sites More sharing options...
Sara_Donald Posted February 2, 2008 Author Report Share Posted February 2, 2008 Im not sure how to do that as the remote VPN Server is a hosted service. I see what is happening, I am using tls to connect to the pbx but then the VPN uses L2TP which uses UDP transport for its VoIP on port 5060. That along with the NAT issues are killing me. I read an article on TLS having problems over L2TP. I am going to change my VPN to OpenVPN as it is better suited to TLS. I will choose a VoIP Company that allows TLS connections. Hopefully that will solve the problems. Kindest Regards, Sara Donald. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.