please unsubscribe me. thanks. >From: "Vijay K. Gurbani" <[EMAIL PROTECTED]> >To: Matthew Gardiner <[EMAIL PROTECTED]> >CC: SIP Implementors <[email protected]> >Subject: Re: [Sip-implementors] [Sip] draft-ietf-sip-connect-reuse-05 >Date: Fri, 30 Jun 2006 09:46:42 -0500 > >[... This thread is migrating here from the SIP WG mailing list. > For a context, please see the archives in the SIP WG > mailing list ...] > >Matthew Gardiner wrote: > > Yes, fair enough. However, this suggestion is unworkable, for > > instance in a situation where the remote end dropped it's connection > > on a timer, and is perfectly willing to accept to a new connection. > > If the transaction was a reINVITE for hold, for example, the caller > > would be left waiting for 32 seconds minimum, before the local stack > > fires Timer B and decides it must initiate a new connection in order > > to place the hold. > >True; good scenario to discuss. > > > As an implementator I'd want a better technique than this. > >In that case, one could architect your software such that the >TLS thread implements a observer pattern between itself >and the worker threads. > >Since the TLS thread knows when the socket is closed (as per >our earlier email exchange), it will simply insert the >approriate event in the worker thread's event queue, or invoke >a callback function, or do whatever to let the worker thread >know that it should take pre-emptive action. > >In the end, it will all boil down to programming techniques. > >Thanks, > >- vijay >-- >Vijay K. Gurbani [EMAIL PROTECTED],research.bell-labs.com,acm.org} >Bell Laboratories, Lucent Technologies, Inc. >2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >_______________________________________________ >Sip-implementors mailing list >[email protected] >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
