Hey,
STUN's new structure starts to be stabilized. I just updated CVS to
contain modifications that should enable STUN NAT type determination
with the asyncrounous API. Next week STUN related work should be that
far that we we could integrate this to tport, too.
This is how it looks now: there are three different kind of STUN
objects.
1. stun_handle has the information of the TLS and UDP sockets, su_root
etc. It also contains the list of stun_requests.
2. stun_request is created for an outgoing transaction. Binding request
is such, for example. The requests are inserted to a linked list in
stun_handle. Currently there are 4 different types of transactions for
binding request, NAT type and lifetime discoveries and SIP keepalives.
Every stun_request starts a timer that holds the re-send mechanism.
Requests are also destroyed by the timer when the stun_discovery process
is finished. Every transaction is associated to a stun_discovery object.
There can be multiple stun_requests for one stun_discovery object.
3. stun_discovery object knows which transactions are already handled,
and based on this information the discovery process can be finalized.
Let's use NAT type determination as an example: First, 3 messages
(stun_requests) with different parameters are sent simultaneously to
STUN server. Responses from the server are handled in the callback and
directed to right state machine, in this case to a NAT determination
state machine. This state machine updates the NAT type information. When
the NAT type can be determined a callback is sent to user application
and requests associated to this discovery object are destroyed when
their timers are launched.
Cool?
Has somebody had time to peek into the get_lifetime mechanism? If not
I'll continue with that next.
BR,
Martti
--
Martti Mela, Nokia Research Center
+358504836460
Changelog follows:
2006-01-05 Martti Mela <[EMAIL PROTECTED]>
* stun.c: Finished get_nattype functionality. Might
work. Different stun actions are now kept in stun_discovery_t
struct.
* stun.h: Updated event to support nattype discovery;
get_nattype
definition, too.
* stunc.c: Support for discovery events
* torture_stun.c: stun_states_t -> stun_state_t
2006-01-04 Martti Mela <[EMAIL PROTECTED]>
* stun.c: Functionality changed to support transactions; initial
support for NAT type discovery
* stun.h: API changed to support transactions
* stun_internal.h: API changed to support transactions
* stun_tag.[ch]: added tag STUNTAG_ACTION for different actions
(lifetime, NAT type, bind, keepalive)
* stunc.c: enabled get_nattype
* torture_stun.c: changed to support new API
*stun_common.h: removed NAT type strings to stun.c.
2005-12-19 Martti Mela <[EMAIL PROTECTED]>
* stun.c: fixed TLS and bind timers.
* stun_common.c: changed every SU_DEBUG to contain __func__.
2005-12-19 Martti Mela <[EMAIL PROTECTED]>
* stun.c: TLS connection works now.
* stun.h: removed stun_socket_t references, replaced by
stun_handle functionality.
* stunc.c, torture_stun.c: modified in accordance to stun.h.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Sofia-sip-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
