Hey Rob, Yes, we are using darcs (mostly with Pekka). Our repository is at [EMAIL PROTECTED]:sofia-sip. Pekka has been kindly granting developer accesses for the tree itself, but maybe you can fetch the tree via http (I haven't tried it :| )?
BR, Martti >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf >Of ext Rob Taylor >Sent: 10. tammikuuta 2006 11:46 >To: Mela Martti (Nokia-NRC/Helsinki) >Cc: [email protected] >Subject: Re: [Sofia-sip-devel] STUN NAT type discovery works (?) > >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=ick >_______________________________________________ >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
