Hi Mike, I removed the apr dependency for timestamp and use the function openzap delivers. Works good so far. For unstabilities in openzap and Q931: On my side main problem seems to be, that channels for inbound traffic sometimes not be freed during runtime. Maybe our remote TDM end (AVAYA) simply doesn't release calls as it should, maybe openzap doesn't catch all q931 messages. I added a hack, which forces channels which are in TERMINATE or beyond *AND* this state is older than e.g. 500ms for inbound SETUP to DOWN. Openzap uses those down forced channels. I have the patch in production and I saw the first aid hack serveral times "InUse" channels freeing. "oz dump 1" shows channel states which hung in TERMINATE or above are down serveral minutes later :) This is just a quite brutal hack because it assumes that the remote TDM end is able to recover channels as well. regards helmut