[... 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
