[OpenSIPS-Devel] "Early cancel" issue in the tm module

[Maxim Sobolev]

Hi Bogdan, happy holidays for you and OpenSIPS team! So, what's the
next step to get those early CANCEL changes merged? Basic testing
seems to be confirming its functionality. I'd also like to get your
opinion on the 100 Trying generation when t_newtran() is used. Thanks!

On Wed, Dec 23, 2015 at 7:07 AM, Maxim Sobolev <sobomax at sippysoft.com> wrote:
> OK, further investigation revealed that the lack of the provisional
> reply is caused by the usage of the t_newtran() in our routing script,
> which then causes different code path in the t_relay(), i.e.
> t_forward_nonack() function is used instead of t_relay_to(). Which
> appears to be triggering a separate bug in the OpenSIPS that affects
> all releases out there. We use t_newtran() to  make sure each request
> is processed only once, otherwise each re transmit would cause
> separate request to the rtpproxy to be generated. I think the fix
> would be to extend t_forward_nonack() to properly generate 100 Trying.
>
> Just in case, our routing script looks like the following:
>
> ==========================
>     ## shield us against retransmits
>     if (!t_newtran()) {
>         sl_reply_error();
>         exit;
>     };
>
>     if (method == "INVITE") {
>         if (rtpproxy_offer("r")) {
>             t_on_reply("1");
>             t_on_failure("1");
>         };
>     };
>
>     if (method == "BYE") {
>         unforce_rtp_proxy();
>     };
>
>     record_route();
>
>     if (loose_route()) {
>         t_relay();
>         exit;
>     };
>
>     if (src_ip == "127.0.0.1" && src_port == 5061) {
>         t_relay("udp:127.0.0.1:5062");
>     } else {
>         t_relay("udp:127.0.0.1:5061");
>     };
> ==========================
>
> Please note that Kamailio does not have neither issue with early
> CANCEL + lost 100, nor this issue. For now I've resolved it by adding
> explicit t_reply("100", "Trying").
>
> On the positive note, you patch seems to be working, thanks. Let me
> know if you want me to open issue wrt that t_newtran's 100 Trying
> problem.
>
> https://github.com/sippy/voiptests/commit/11a6bc6bee1ddfc83eb4acf784ce7aebf8e6815b
>
> On Wed, Dec 23, 2015 at 5:05 AM, Maxim Sobolev <sobomax at sippysoft.com> wrote:
>> Sorry, Bogdan, please disregard my previous message. After closer look
>> at the log it seems that my initial diagnosis was not quite correct.
>> The problem appears that provisional response generation is broken
>> somehow, so that the originating UA keeps sending INVITEs over and
>> over again and could not initiate outbound CANCEL at all until 180
>> comes in.
>>
>> 00:00:07.297/GLOBAL/alice_ua: RECEIVED message from 127.0.0.1:5060:
>> SIP/2.0 180 Ringing
>>
>> I am investigating as to what could be a problem, looks like this
>> condition might have been hidden and just exposed now. It seems that
>> it has nothing to do with the change in question.
>>
>> On Wed, Dec 23, 2015 at 4:20 AM, Maxim Sobolev <sobomax at sippysoft.com> wrote:
>>> Hi Bogdan, that patch is not fully functional. Yes, it did restore
>>> INVITE re-transmits, so that the second 100 Trying is stimulated
>>> properly, but the CANCEL to the egress call leg is not generated until
>>> 180 Ringing response comes in. You can see full log here:
>>>
>>> https://s3.amazonaws.com/archive.travis-ci.org/jobs/98496601/log.txt
>>>
>>> See Call-ID: a0f27d0745c1a6b52348900c67362be8 at 172.17.0.79 for an example:
>>>
>>>
>>> On Mon, Dec 14, 2015 at 5:31 PM, Bogdan-Andrei Iancu
>>> <bogdan at opensips.org> wrote:
>>>> Maxim,
>>>>
>>>> Please check the attached patch for 1.11
>>>>
>>>> Regards,
>>>>
>>>> Bogdan-Andrei Iancu
>>>> OpenSIPS Founder and Developer
>>>> http://www.opensips-solutions.com
>>>>
>>>> On 14.12.2015 22:46, Maxim Sobolev wrote:
>>>>>
>>>>> Thanks Bogdan, I will be working on test case this week. I'll drop you
>>>>> a note when it's ready.
>>>>>
>>>>> On Fri, Dec 11, 2015 at 8:42 AM, Bogdan-Andrei Iancu
>>>>> <bogdan at opensips.org> wrote:
>>>>>>
>>>>>> Roger that, thanks for the detailed explanations - let's be consistent in
>>>>>> handling the INVITE cancelling, in terms of letting all the time the
>>>>>> final
>>>>>> UAS to generate the final reply (if still alive).
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Bogdan-Andrei Iancu
>>>>>> OpenSIPS Founder and Developer
>>>>>> http://www.opensips-solutions.com
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Maksym Sobolyev
>>> Sippy Software, Inc.
>>> Internet Telephony (VoIP) Experts
>>> Tel (Canada): +1-778-783-0474
>>> Tel (Toll-Free): +1-855-747-7779
>>> Fax: +1-866-857-6942
>>> Web: http://www.sippysoft.com
>>> MSN: sales at sippysoft.com
>>> Skype: SippySoft
>>
>>
>>
>> --
>> Maksym Sobolyev
>> Sippy Software, Inc.
>> Internet Telephony (VoIP) Experts
>> Tel (Canada): +1-778-783-0474
>> Tel (Toll-Free): +1-855-747-7779
>> Fax: +1-866-857-6942
>> Web: http://www.sippysoft.com
>> MSN: sales at sippysoft.com
>> Skype: SippySoft
>
>
>
> --
> Maksym Sobolyev
> Sippy Software, Inc.
> Internet Telephony (VoIP) Experts
> Tel (Canada): +1-778-783-0474
> Tel (Toll-Free): +1-855-747-7779
> Fax: +1-866-857-6942
> Web: http://www.sippysoft.com
> MSN: sales at sippysoft.com
> Skype: SippySoft



-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sales at sippysoft.com
Skype: SippySoft