[reSIProcate] STUN Client support
- From: "Matthias Moetje - TERASENS GmbH" <moetje@xxxxxxxxxxxx>
- Date: Thu, 6 Apr 2006 21:44:59 +0200
Hi,
I just finished
the implementation of STUN client support.
It was much easier
than I had expected and it works
quite well. (I
haven't solved the via problem yet, though)
This is what I've
done:
SipStack::AddTransport now returns a pointer of type
"Transport"
to the internally
created transport. This pointer can be casted
back to a
UdpTransport interface (for STUN client usage).
I added the
following new member variables:
mutable resip::Mutex myMutex;
Tuple mStunMappedAddress; //
the discovered mapped address
bool mStunSuccess; // received a
successful response to last STUN test
and these two
public functions:
bool
stunSendTest(const Tuple& dest);
bool stunResult(Tuple&
mappedAddress);
The first one lets
you initiate a STUN test to the STUN
server specified
by "dest". It constructs a STUN message
and adds it to the
"mTxFifo".
The latter function just returns the discovered mapped
address
and port in case
the last STUN test was successful.
I added some code
to the process function in order to process
the STUN response.
It checks the first two bytes (very
similar to the
existing implementation of STUN server):
if (buffer[0] == 1 && buffer[1] ==
1 && ipVersion() == V4)
I changed the STUN
server message detection from
if (buffer[0] == 0 || buffer[0] == 1
&& ipVersion() == V4)
(which was
obviously wrong) to
if (buffer[0] == 0 && buffer[1] ==
1 && ipVersion() == V4)
Finally I added a
Lock to the two STUN functions and to the process
function for
thread safety.
If nobody has some
serious reasons against this implementation
I would check it
in soon, I don't think this will affect existing
applications
in any
way because the mutex is the only real
effective change
for someone who doesn't use STUN client
or server
functionality.
Best regards,
Matthias Moetje
|
TERASENS
GmbH Augustenstraße 24 80333 Munich GERMANY |
|
|