[Serusers] STUN characteristics

sip sip at arcdiv.com
Wed Sep 20 16:42:50 CEST 2006


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.



More information about the sr-users mailing list