5 Apr
2006
5 Apr
'06
4:21 p.m.
Hi,
We are using SIPPS as the softphone for our ISP customers, all of whom
are on DSL and behind some sort of NAT'ed firewall.
SIPPS does not always pick up the need for STUN when it checks the
network, and then the user has problems until STUN is enabled.
My question is - would there be any downside in us just hard coding the
client to use STUN, given that the end user is a home user on DSL?
Thanks.
--
-Barry Flanagan
5 Apr
5 Apr
6:14 p.m.
Barry Flanagan wrote:
Hi,
We are using SIPPS as the softphone for our ISP customers, all of whom
are on DSL and behind some sort of NAT'ed firewall.
SIPPS does not always pick up the need for STUN when it checks the
network, and then the user has problems until STUN is enabled.
My question is - would there be any downside in us just hard coding the
client to use STUN, given that the end user is a home user on DSL?
There are 2 usages of STUN.
1. to detect if the client is behind NAT and which version of NAT
2. if in 1. is detected that the client is behind NAT and this NAT can
be traversed by STUN, then STUN will be used to detect public IP:port
and to make the keep-alive.
Usually, if the SIP client has a STUN server configured, it will do step
1, and according to the result of step 1 it will do step 2.
Thus, a STUN server should always be configured. Then, the client is
able to do step 1 and if necessary step 2.
If you have problems, then either the client is buggy in step 1 or there
are bad NATs which change behaviour and SIPPS thinks that step 2 is not
necessary although it is necessary.
By "always enable STUN" it depends on what the client exactly does,
because if the client is behind symmetric NAT (detected in step 1), step
2 MUST NOT be executed as it will fail.
Thus, it depends on the exact implementation of "always use STUN" in the
client.
regards
klaus
6816
days inactive
6816
days old
1 comments
2 participants
participants (2)
-
Barry Flanagan -
Klaus Darilion