Martti, cool stuff :) I was wondering, do you have a darcs repo where you're doing this work?
Thanks, Rob Taylor [EMAIL PROTECTED] wrote: > Hey José and others, > > The first version of working (?) STUN lifetime determination has been > available at the CVS since yesterday. I am not 100 % convinced of the > lifetime timeouts (in stun_common.h), they might need to be 10 times bigger. > > Please try it and test also NAT type determination if you happen to have some > NATs available ;) > > Now all the transactions (stun_request_t) are destroyed by their timers. It's > done in the following way: when a response to a transaction is found and the > discovery operation updated, a callback to user is launched. After this the > transaction's state is set to "stun_dispose_me". At some point, when the > timer launches, the request is then destroyed by stun_destroy_request(). > > Today we'll start to merge these mods to tport, hold thumbs for the next > release! > > BR, > > Martti > > > > ________________________________ > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext > Abner José > Sent: 6. tammikuuta 2006 19:24 > To: [email protected] > Subject: Re: [Sofia-sip-devel] STUN NAT type discovery works (?) > > > Hi Martti, > > Really great news about STUN and I'll test it ASAP! > Well, about the get_lifetime mechanism I was working on it, but now > it's stoped because I have some vacation days! ;) > I'll come back to work in the half of current month and I can keep > working on get_lifetime, if you don't finish it in the next week. > If you want to talk with me I'm keep reading the sofia mailinlist ... > > BR > > - Birunko > > > On 1/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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] <mailto:[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] <mailto:[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&opclick > _______________________________________________ > Sofia-sip-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > > > > > > -- > current->id = 0; > >> Powered by Linux > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
