Bruce,
thanks very much for looking into
this.
> Actually, I don't understand what the
lock is doing here.
The lock is there to protect
the mStunSuccess variable from being modified by another thread
during execution of one of the three functions (process, stunSendTest,
stunResult).
In fact it does not seem necessary to lock
the mutex right at beginning of the Process function (I put it there before I
noticed that the txFiFo is protected by a mutex anyway). I will move it behind
the if statement that detects a STUN response so that it only gets locked when a
STUN response is atually received. So we can turn down at least this concern
:-)
> 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)
Actually for me the ideal solution would be
a userprofile flag that tells the stack to use a detected public mapped tuple
for sending. All of the STUN detection stuff could be done by the transport
then. I see no benefit in letting the application deal with STUN message sending
and let these messages travel all the way through the stack. (The way this needs
to be implemented should be quite standard and not application
specific.)
> So if there's a lock, it actually
needs to be in place to prevent a
> second call to stunSendTest from
returning until stunResult has
> completed successfully. But I'm
pretty sure we don't want to do
> that, either.
Of course not because we never know if we
will get a response or if the packet will get lost. When you look at the
current way I'm using the STUN functions from my application (please
see wiki) you will see that there is no problem that there is only a
single request. Because
- 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)
> - 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.
> 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 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 :-)
> There's also an interesting question
of whether we would want to
> implement KeepAlive messages using the
same interface.
The current implementation can easily be
used to keepalive a current NAT mapping, just call stunSendTest
regularly.