From MAILER-DAEMON Tue Feb 21 08:23:41 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1cgAPt-00039k-DI for mharc-osip-dev@gnu.org; Tue, 21 Feb 2017 08:23:41 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33214) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgAPl-00033V-SL for osip-dev@gnu.org; Tue, 21 Feb 2017 08:23:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cgAPh-00053F-Ux for osip-dev@gnu.org; Tue, 21 Feb 2017 08:23:33 -0500 Received: from www1.planinternet.net ([93.189.168.31]:46911) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cgAPh-0004tv-Nd for osip-dev@gnu.org; Tue, 21 Feb 2017 08:23:29 -0500 Received: from [192.168.2.3] ([::ffff:84.161.129.199]) (AUTH: LOGIN planin01_01, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by www1.planinternet.net with ESMTPSA; Tue, 21 Feb 2017 14:23:20 +0100 id 0000000000440045.0000000058AC3F48.000064E3 To: osip-dev@gnu.org From: Roger Schreiter Message-ID: <1220915f-41dc-6b79-15bd-64c6cb25864b@planinternet.de> Date: Tue, 21 Feb 2017 14:23:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------1E87F13F6DA4635D458A81E2" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 93.189.168.31 Subject: [osip-dev] strange behaviour with incoming OPTIONS request X-BeenThere: osip-dev@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: osip/exosip mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 13:23:40 -0000 This is a multi-part message in MIME format. --------------1E87F13F6DA4635D458A81E2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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. --------------1E87F13F6DA4635D458A81E2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 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.

--------------1E87F13F6DA4635D458A81E2-- From MAILER-DAEMON Tue Feb 21 09:46:17 2017 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1cgBhp-0004b0-B5 for mharc-osip-dev@gnu.org; Tue, 21 Feb 2017 09:46:17 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgBhm-0004YZ-P4 for osip-dev@gnu.org; Tue, 21 Feb 2017 09:46:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cgBhl-0001JX-67 for osip-dev@gnu.org; Tue, 21 Feb 2017 09:46:14 -0500 Received: from mail-lf0-x22c.google.com ([2a00:1450:4010:c07::22c]:34469) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cgBhk-0001HK-Oj for osip-dev@gnu.org; Tue, 21 Feb 2017 09:46:13 -0500 Received: by mail-lf0-x22c.google.com with SMTP id g134so21909283lfe.1 for ; Tue, 21 Feb 2017 06:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DL/ICMEowtKhsdniLlMjpnZez6SkNmv6J9xsDsSrytc=; b=dnZAj80DsGEJSUftACt1UWK+xkqgA/KtwZwojVaQ6ckGAq8UC5tmuDXbvYvJKZWuW9 PiV3iVKXeSSPeBP0IoLv/pwPPAZPB/oVDfT24O3mW0hDOheXO+5cRVvTLb+g2zSpsduz g2iqQAKgEfKBGPLOFIgJYwNlLYa6ZxvHdHMheAAKQCLl0WW6zFBiGumMJGlSZHS7f70U AAv/Xl9lFqoWmIwS4yHZUO6/Fj7g/+dNxxpRI6MVnBN466IL0MZY0KS/YrQUDoeUYF7m 5LIMrLYftQHcjm2/INv45ezTHVbgu7TqTefin+hWCcybZuSlhbLhCDI/beDq9QOOUvio WhIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DL/ICMEowtKhsdniLlMjpnZez6SkNmv6J9xsDsSrytc=; b=nbapqrPl2kqLnxrwIiYmhEe3HCvQn5KUKw0wB38uNfxA0QOrcpT9dQWYY1Gajt2Qa2 LvjQHYv0nJ1/WAelVSVaXAXXytSTG2QNwglHNWz343eXjDDHwo8QrUHvKMzDW140EtRI 0C8Df8YooaJ+FeiCv8VdwaKvUG0jmQlMVOsF9npgfgSFJs/9smmvZdFf30aiVGfEituI 7YGTRkMe9CHV9KrIloXxdjfnaDzZLT1lCj3liWyevlE41He/ttlZpR4utQLlxxeCl3nu GR78o7rvy29z6hyELVtXk0qSi+9e1cclRCt7h0VJ12pgVWtWqHorIU2ATBvDubwTMKMH 6pwg== X-Gm-Message-State: AMke39lb8y1m/C+JEY5BFNiNeYwEqf41p4dJ/WY+jIXPBkTWGe8IAJEFBQ3FbmqduFFaRTarZIud5OptwOs1UA== X-Received: by 10.25.145.5 with SMTP id t5mr2110238lfd.91.1487688369453; Tue, 21 Feb 2017 06:46:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.150.141 with HTTP; Tue, 21 Feb 2017 06:46:09 -0800 (PST) In-Reply-To: <1220915f-41dc-6b79-15bd-64c6cb25864b@planinternet.de> References: <1220915f-41dc-6b79-15bd-64c6cb25864b@planinternet.de> From: Aymeric Moizard Date: Tue, 21 Feb 2017 15:46:09 +0100 Message-ID: To: Roger Schreiter Cc: "osip-dev@gnu.org" Content-Type: multipart/alternative; boundary=94eb2c1cd5d0cc3fb005490b70ca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::22c Subject: Re: [osip-dev] strange behaviour with incoming OPTIONS request X-BeenThere: osip-dev@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: osip/exosip mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 14:46:16 -0000 --94eb2c1cd5d0cc3fb005490b70ca Content-Type: text/plain; charset=UTF-8 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 request If 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 : > 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 > osip-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/osip-dev > > -- Antisip - http://www.antisip.com --94eb2c1cd5d0cc3fb005490b70ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 request

If you are using UDP, transaction context are kept 64= *T1 seconds in order to
reply to retransmissions.

<= /div>
- Would= it be save to kill that transaction from within the "send messge call= back"?

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 th= e resent OPTIONS requests are no more detected as OPTIONS request?


If a retransmission of a non-INVITE request is receive= d, it should call the method
attached to OSIP_NIST_REQUEST_RECEIV= ED_AGAIN.

This method is set like this:
= osip_set_message_callback (osip, OSIP_NIST_REQUEST_RECEIVED_AGAIN, &cb_= rcvreq_retransmission);

First OPTION request r= eceived will call the method attached to=C2=A0OSIP_NIST_OPTIONS_RECEIVED:

This method is set like this:
= osip_set_message_callback (osip, OSIP_NIST_OPTIONS_RECEIVED, &cb_rcvreq= uest);

So if you set different methods for tho= se events, different methods will be called!

retra= nsmission do not need to be announced to app layer, this is why there is
a different callback for them!

Hope that a= nswer all your questions!

Regards,
Aymer= ic



2017-02-21 14:23 GMT+01:00 Roger Schreiter <rog= er@planinternet.de>:
=20 =20 =20
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&= quot; 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 "sen= d messge callback"?
- Why the resent OPTIONS requests are no more detected as OPTIONS request?

Regards,
Roger.


_______________________________________________
osip-dev mailing list
osip-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/osip-dev<= /a>




--
--94eb2c1cd5d0cc3fb005490b70ca--