20 Sep
2006
20 Sep
'06
10:42 a.m.
I'm doing an experiment with our userbase at the moment, making some
modifications to allow more users to register than who'd been allowed to
register before (to minimise the amount of bandwidth we need to use for our
services, we are trying to absolutely minimise the number of users that
require the use of an RTPproxy, since, in a userbase of 100,000 users, this
can be rather pricey if there are too many of them which require it).
We used to not allow anyone with a contact header that was NOT a public IP
address to register onto the system, with the assumption that they could use
STUN and it SHOULD rewrite the contact header. This assumption has proven to
be... optimistic. Several of the UAs we see show radically different
characteristics during this 'open' trial, and I'm not sure if they're
just
differing STUN versions or if our users simply can't follow the
install/configure instructions.
SO... my question becomes: what are the characterstics of functioning STUN
implementations and how they should overwrite contact/via/sdp headers for the
UA's messages?
Most every one of the STUN implementations I've seen rewrites the Contact
header and the data inside the O and C lines in the SDP header. Most of them
seem to overwrite the Via headers with valid information as well, although not
all of them do.
What are some other things I should be looking for?
I'm trying to essentially test for a particular variant of STUN, allowing
users who've at least followed the instructions to the letter to have working
and usable clients (perhaps using RTP proxy where needed) while not allowing
users who're still attempting to use private IPs for everything to waste our
bandwidth because they're not following the instructions or they're using a UA
that is, in effect, broken in its implementation.
This is a lot more complex than it sounds, I know, but I think if I have more
data to work with, I might be able to come up with a more acceptable scenario
than we currently employ.
N.
20 Sep
20 Sep
2:47 p.m.
This is a lot more complex than it sounds, I know, but
I think if I have more
data to work with, I might be able to come up with a more acceptable scenario
than we currently employ.
We too tried to use STUN as often as possible with all our users. Its
fine at the beginning because you can fine tune everybody when you have
a small customer base. As our network grew we found ourselves taking in
more and more customer support calls from clients using STUN. The most
common problem one had to deal with was that of NO Audio with customers
changing routers from simple 'cone NAT' to 'symmetric NAT' type which of
course breaks STUN. In the end we found it a lot more economical to pay
for more bandwidth and use multiple RTP Proxy servers than to pay for
more Tech Support people. It has worked out beautifully. I can't
remember that last support call we ever had from somebody complaining
about no audio. It had to be more that 2 years ago.
--
Andres
Technical Support
http://www.telesip.net
21 Sep
21 Sep
9:23 p.m.
At 20:47 20/09/2006, Andres wrote:
Whereas I don't add any new information value, let me at least concur that this is the
bottom line.
It is what it is which is an economic decision driven by cost incurred through some STUN
unreliablity.
in the long-run, the standardization answer to lacking reliability is via ICE, but
that's something
today's deployments cannot rely on yet.
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
This is a lot
more complex than it sounds, I know, but I think if I have more
data to work with, I might be able to come up with a more acceptable scenario
than we currently employ.
We too tried to use STUN as often as possible with all our
users. Its fine at the beginning because you can fine tune everybody when you have a
small customer base. As our network grew we found ourselves taking in more and more
customer support calls from clients using STUN. The most common problem one had to deal
with was that of NO Audio with customers changing routers from simple 'cone NAT'
to 'symmetric NAT' type which of course breaks STUN. In the end we found it a lot
more economical to pay for more bandwidth and use multiple RTP Proxy servers than to pay
for more Tech Support people. It has worked out beautifully. I can't remember that
last support call we ever had from somebody complaining about no audio. It had to be more
that 2 years ago. 
22 Sep
22 Sep
1:48 a.m.
I agree with Andres, it is cheaper to invest in hardware than customer
service...
However, the nat_uac_test("16") will detect many faulty ALGs and STUN
behind symmetric NAT because even though the SIP message seems to be
with public IPs, the port in the via will not match the received port.
Of course, there will still be ALGs that manages to replace contact and
via with the correct port (and SDP with correct IP), but still manages
to mess up SDP ports.
I have found Delta Three's document on NAT to be one of the best written
on the various types of NAT and solutions to solve it:
http://corp.deltathree.com/technology/networkaddress.asp
g-)
Andres wrote:
This is a lot more complex than it sounds, I
know, but I think if I
have more
data to work with, I might be able to come up with a more acceptable
scenario
than we currently employ.
We too tried to use STUN as often as possible with all our users. Its
fine at the beginning because you can fine tune everybody when you
have a small customer base. As our network grew we found ourselves
taking in more and more customer support calls from clients using
STUN. The most common problem one had to deal with was that of NO
Audio with customers changing routers from simple 'cone NAT' to
'symmetric NAT' type which of course breaks STUN. In the end we found
it a lot more economical to pay for more bandwidth and use multiple
RTP Proxy servers than to pay for more Tech Support people. It has
worked out beautifully. I can't remember that last support call we
ever had from somebody complaining about no audio. It had to be more
that 2 years ago.
21 Sep
21 Sep
9:17 p.m.
I think signaling may be simplified if you wish. Just assume symmetric
signaling (Clients that dont do it should be trashed), generate
rported replies, rewrite contacts and that's it.
Media is harder that's where actually STUN is the tool that helps so
much because it saves RTP bandwidth. It is up to you to select the
most robust test for whether to engage RTP proxy in a call or not,
but I think that private IP addresses in SDP are a safe indication
for public SIP service you should.
-jiri
At 16:42 20/09/2006, sip wrote:
I'm doing an experiment with our userbase at the
moment, making some
modifications to allow more users to register than who'd been allowed to
register before (to minimise the amount of bandwidth we need to use for our
services, we are trying to absolutely minimise the number of users that
require the use of an RTPproxy, since, in a userbase of 100,000 users, this
can be rather pricey if there are too many of them which require it).
We used to not allow anyone with a contact header that was NOT a public IP
address to register onto the system, with the assumption that they could use
STUN and it SHOULD rewrite the contact header. This assumption has proven to
be... optimistic. Several of the UAs we see show radically different
characteristics during this 'open' trial, and I'm not sure if they're
just
differing STUN versions or if our users simply can't follow the
install/configure instructions.
SO... my question becomes: what are the characterstics of functioning STUN
implementations and how they should overwrite contact/via/sdp headers for the
UA's messages?
Most every one of the STUN implementations I've seen rewrites the Contact
header and the data inside the O and C lines in the SDP header. Most of them
seem to overwrite the Via headers with valid information as well, although not
all of them do.
What are some other things I should be looking for?
I'm trying to essentially test for a particular variant of STUN, allowing
users who've at least followed the instructions to the letter to have working
and usable clients (perhaps using RTP proxy where needed) while not allowing
users who're still attempting to use private IPs for everything to waste our
bandwidth because they're not following the instructions or they're using a UA
that is, in effect, broken in its implementation.
This is a lot more complex than it sounds, I know, but I think if I have more
data to work with, I might be able to come up with a more acceptable scenario
than we currently employ.
N.
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
6537
days inactive
6539
days old
4 comments
4 participants
participants (4)
-
Andres -
Greger V. Teigre -
Jiri Kuthan -
sip