NAT problems with Snom 300 on 2.0.3.1708 (Unix)

[Jan Forcier]

I'm getting the classic "one way audio" (NAT blocking one call leg) with Snom 300, firmware 6.5.8 on 2.0.3.1708 (Unix)

I used PBXnSIP to provision the phone and confirmed that the outbound proxy is/was set to the server correctly.

 

The Snom 300 registers, but one audio leg (inbound to the phone) gets blocked behind a NAT.

Is this a problem with the build or with Snom 300

[Vodia PBX]

I guess you are not using STUN on the phones?

 

So far it seems that other installations do not have such a problem.

 

You can do PCAP traces both from the phone and from the PBX - then it should be easy to see where the RTP gets lost.

[Jan Forcier]

I guess you are not using STUN on the phones?

 

So far it seems that other installations do not have such a problem.

 

You can do PCAP traces both from the phone and from the PBX - then it should be easy to see where the RTP gets lost.

[Jan Forcier]

No, my understanding is that PBXnSIP does not *have* STUN so I don't have a STUN server to use.

I'm using outbound proxy but this does not appear to work

 

JF

 

I guess you are not using STUN on the phones?

 

So far it seems that other installations do not have such a problem.

 

You can do PCAP traces both from the phone and from the PBX - then it should be easy to see where the RTP gets lost.

[Vodia PBX]

No, my understanding is that PBXnSIP does not *have* STUN so I don't have a STUN server to use.

 

The trunk may use STUN to allocate a public IP address. This is very unreliable, therefore we strongly recommend not to use this feature. However, there are stupid marketing people who believe that if that feature does not show up in the datasheet the product is inferior. We all know that this is bulls*** and STUN is just creating huge support problems.

 

When an extension registers, it should just point the outbound proxy towards the PBX. On the snom phones, you can use even use TCP (or TLS) transport layer. Just use an outbound proxy like "sip:2.3.4.5:5060;transport=tcp". Then the NAT problems should also disappear, because even crappy routers support TCP connections. Of course, do not use STUN on the phones as well.

[Jan Forcier]

I am using outbound proxy and not STUN at the same time on the device. I'm also not using it on a server trunk since the server is on the open internet, no firewall

As I mentioned in the original post, I am using outbound proxy (on the device) exactly as described.

 

The NAT is a Linksys NAT with fully updated firmware.

However, I've noted that other ATA's (Linksys) also seem to have be getting blocked by NAT which does not happen on earlier builds.

 

Still does not work. Are you sure that this build does not have "outbound proxy" support broken?

 

JF

 

FYI:

I've been using PBXnSIP for more than a year and I doubt I'm making a trivial error.

 

I provisioned the factory default blank Snom 300 UA using PBXnSIP (this was really what I was testing) so if any settings are wrong, then there is a problem with the provisioning.

Essentially my procdure was:

1) Take new Snom 300 from box, upgrade to newest firmware

2) Provision using PBXnSIP

3) Add, OP to account. The UA put in "sip:66.119.176.21:5061;transport=tcp" after I saved. (this is the IP of my server, not sure why it wanted to use 5061 but I don't see why this would be a problem

4) Test, find I'm getting one way audio

- I then tried some troubleshooting but can't find a problem so I posted to your forum.

 

JF

 

 

The trunk may use STUN to allocate a public IP address. This is very unreliable, therefore we strongly recommend not to use this feature. However, there are stupid marketing people who believe that if that feature does not show up in the datasheet the product is inferior. We all know that this is bulls*** and STUN is just creating huge support problems.

 

When an extension registers, it should just point the outbound proxy towards the PBX. On the snom phones, you can use even use TCP (or TLS) transport layer. Just use an outbound proxy like "sip:2.3.4.5:5060;transport=tcp". Then the NAT problems should also disappear, because even crappy routers support TCP connections. Of course, do not use STUN on the phones as well.

[Vodia PBX]

In the end, only a PCAP trace (either from the phone or from the PBX) helps. snom phones support making PCAP traces right from the phone. Then we see if it gets media at all, and we can see if someone in the middle is blocking the traffic. There are also other possible problems like wrong SRTP MAC, which also result in one-way audio. The PCAP trace will help to hunt them down.

 

A very simple way is also looking at the statistics in the BYE packets. Both the PBX and the snom phones sends a Rx/Tx statistics. You can match them and see if there must have been a significant packet loss. That would help to find the problem even without having PCAP traces.

 

If we find the problem, we can later say if it was "trivial" or not :-))