Re: [reSIProcate] Fwd: [reSIProcate-commit] COMMIT: resiprocate 6128moetje: Added STUN client support
Matthias,
I completely agree that your code solves 95% of NAT situations, i.e.
where you have a node behind an independent mapping NAT and all
communication goes to nodes on the other side of that NAT. As long as
the application never lets the NAT mapping expire, that problem is
completely solved.
My concern is directed more at trying to find a solution for the other
5% of the problems and to make sure the solution preserves
compatibility with a few of the newer protocols being developed (at
least at the level of making sure implementing them doesn't become
harder).
On 4/13/06, Matthias Moetje - TERASENS GmbH <moetje@xxxxxxxxxxxx> wrote:
>
>
> > There's a general issue, though, that this interface only supports
> > a single outstanding stun request, which really isn't going to be
> > sufficient for more complicated UAC/UAS code.
>
>
> I'm not quite sure what kind of "complicated UAC/UAS" scenanrios you are
> refering to. The STUN information is always specific to each UDP transport,
> i.e. each UDP transport has exactly one public mapped ip address and port no
> matter how complicated the UAS/UAS scenarios are that use the transport. (At
> least if we are talking about current STUN implementations that can't deal
> with symmetric NATs)
Unfortunately, there's a lot of ground between an address and port
independent mapping NAT and a full symmetric NAT.
draft-ietf-behave-nat-udp-05 discusses a lot of examples of bizarre
behavior that NATs can produce. Two of the big issues have apparently
been large commercial NATs and NATs that change their mapping behavior
as they get more heavily loaded.
> - all requests are identical (sent to the same STUN server)
>
> - several requests may be sent that set the flag to false, but
> as soon as requests are received the flag will be set to true
> and as soon as the flag is true the application does not send
> any more tests. (for a certain interval at least)
again, for the simple example, this works. For the more complex
network setups, it fails. Actually, the certain interval probably
means there needs to be some way to result the result flag already.
>
>
>
> > - Primarily, have you taken a look at rfc3489bis-03 or recent drafts?
> > The usage has changed a bit. I have a student who's working on
> > implementing the new version, and we hope to be able to contribute
> > that in the near future.
>
>
> I haven't had a look at this yet. My focus is on making this work with
> current implementations.
>
>
> > - One of the key behaviors needed is the ability to issue a binding
> > query/connectivity check to any arbitrary destination, and in fact
> > there may be multiple outstanding queries. This implies that the
> > stun request needs to probably return a handle or require a
> > conventional event handler so that replies can invoke the handler
> > with a handle to match the specific stun request.
>
>
> OK, this is nice, but this is incompatible with current SIP implemenations.
> You can't rely on the other party being able to respond to STUN requests on
> their SIP ports. Even in reSIProcate this is disabled by default. So I think
> for the near future we will continue to rely on an external STUN server.
I'm not trying to suggest that we do anything that would break the
single-external-stun-server model, but since it's well-established
that there are a lot of shortcomings with that model and since several
new proposals are evolving that address these shortcomings, I think it
would be best if resiprocate tries to support them somewhat.
>
>
> > We should make sure that whatever the design is, it provides
> > the services necessary to higher layers can implement ICE on
> > top of this.
>
>
> Please correct me if I'm wrong, I just had a brief look over the ICE
> concept, but as far as I understand it so far I'd say: Everything that ICE
> adds to STUN (and that is mainly the ability to traverse symmetric NATs)
> would need to be implemented in the media/RTP stack, not at the SIP layer.
>
> For symmetric NAT traversal on the SIP layer I see the following two
> concepts:
>
> - A UAS or UAC just replies to the IP address/port where it
> received the packet from and ignores via/contact
> (I think this is mentioned in the ICE specs?)
>
> - STUN communication is done with the remote party directly
> over the actual SIP ports instead of an external STUN server
>
I believe ICE requires STUN support from both the peers and an
external STUN server. I think it's a bit of an oversimplification to
say that it adds support for symmetric NATs. It adds supports for a
lot of more complicated scenarios (contacting nodes both inside and
outside the NAT, for example).
You're right that it's a lot more complex since it requires
interaction between the RTP/RTCP and the SIP connection. I don't
think I fully understand the requirements yet, either.
>
>
> > I like the ability to create a StunMessage the same way a
>
> > SipMessage is created for something like Register, which
> > allows either a simple call to create the standard STUN
> > messages, but a more advanced use can be made by
> > manipulating the StunMessage directly.
>
>
> Personally I'd prefer a UdpTransport that performs all STUN functionality
> automatically :-)
>
Yeah, I don't think this should be the only way to do it, but for
applications that need to have more control, a higher-level interface
would be useful.
Bruce