[Serusers] STUN characteristics

[Jiri Kuthan]

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 at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers

--
Jiri Kuthan            http://iptel.org/~jiri/