[osip-dev] strange behaviour with incoming OPTIONS request

[Roger Schreiter]

Hello,
thanks to a network problem, I discovered a behaviour in libosip2, which I do not understand.

Carrier A is sending OPTIONS request once a second from several of his peers. So many requests per second.
(I do not want that, but, since it is an important carrier, I cannot change it.)

Due to a network problem, Carrier A is not receiving our responses, causing resents of those OPTIONS requests.

What do I see in libosip2, is:

OPTIONS request comes in, no transactions is found for this incoming message, my application is creating a new transaction and pushing the messge to libosip2.

Then libosip2 calls the callback function for "options received" as expected.

My application is generating an 200 Ok, passing it to libosip2, and libosip2 calls the send-callback, which is sending the message.

However, it takes a long time (32 secs), before libosip2 is killing the transaction.

When the peer resends the OPTIONS request, libosip2 finds the previous transaction, and my application is appending the new request to that transaction.

Then, libosip2 calls the call back for "received request" (not the one for options received). libosip2 does no more realize that message as OPTIONS request.

Thus, I have three remarks/questions:
- Why the transaction is living that long?
- Would it be save to kill that transaction from within the "send messge callback"?
- Why the resent OPTIONS requests are no more detected as OPTIONS request?

Regards,
Roger.