hello Henning

mmm maybe could be but i wouldn't have expected that. Seems the call is a call in where we receive a BYE from callee before que first ACK in sent from the caller (dialog in state 3). So i was using async_ms_sleep to delay it 250ms and try to avoid 200ok (of the first invite) retransmissions. In some other configurations we also use that async delay.
The difference here is we used async_route (in secs) before, and now used async_ms_sleep. Anycase the actions done after are the same.

Could it be any issue with the usage of the delay of ms?

thanks a lot and best regards
david


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.