Hi Roger,
- Why the transaction is living that long?
Timer J 64*T1 for UDP Section 17.2.2 Wait time for
0s for TCP/SCTP non-INVITE requestIf you are using UDP, transaction context are kept 64*T1 seconds in order to
reply to retransmissions.
- Would it be save to kill that transaction from within the "send messge callback"?
Unlike TCP, UDP requires to handle retransmissions in the application layer and it would be
a bug to not way for retransmission at all.
- Why the resent OPTIONS requests are no more detected as OPTIONS request?
If a retransmission of a non-INVITE request is received, it should call the method
attached to OSIP_NIST_REQUEST_RECEIVED_AGAIN.
This method is set like this:
osip_set_message_callback (osip, OSIP_NIST_REQUEST_RECEIVED_AGAIN, &cb_rcvreq_retransmission);
First OPTION request received will call the method attached to OSIP_NIST_OPTIONS_RECEIVED:
This method is set like this:
osip_set_message_callback (osip, OSIP_NIST_OPTIONS_RECEIVED, &cb_rcvrequest);
So if you set different methods for those events, different methods will be called!
retransmission do not need to be announced to app layer, this is why there is
a different callback for them!
Hope that answer all your questions!
Regards,
Aymeric
2017-02-21 14:23 GMT+01:00 Roger Schreiter <address@hidden>:
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.
_______________________________________________
osip-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/osip-dev