Logs: RTP what does it mean

[Sara_Donald]

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.

[andrewgroup]

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?

[Sara_Donald]

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.

[Vodia PBX]

[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...

[andrewgroup]

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...

[Sara_Donald]

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.

[andrewgroup]

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,

[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,

 

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.

[brandywinetech.com]

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

[andrewgroup]

Agreed on all points with The Monkey. Gee I need a great picture, I'm thinking a Horse Shoe. Something Colt Like.

[Sara_Donald]

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.

[andrewgroup]

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?

[Sara_Donald]

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.

[andrewgroup]

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

[Sara_Donald]

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.

[andrewgroup]

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

[brandywinetech.com]

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

[Sara_Donald]

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.