[OpenSIPS-Devel] "Early cancel" issue in the tm module
Bogdan-Andrei Iancu
bogdan at opensips.org
Mon Jan 11 12:27:39 CET 2016
Hi Maxim,
A Happy New Year to you too ! Sorry for the slow reply, many things to
catch up with.
So, I understand the original problem (retransmissions and cancelling
for slowly answered invites) is solved by the patch I sent you. Hoping
the are no side effects on this change, I can start scheduling it to be
pushed to the public repo as fix to the maintained opensips versions.
On the second issue (with the 100 Trying), I'm not sure I understand the
problem : there is a mentioning of a bogus 100 Trying and also a work
around of forcing the 100 Trying from script.
Could you please detail a bit the actual bug ?
Thanks and regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 29.12.2015 08:01, Maxim Sobolev wrote:
> 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
>
>
More information about the Devel
mailing list