[OpenSIPS-Devel] No 100 Trying reply generated by the t_relay() for INVITE after t_newrean() [was: "Early cancel" issue..]
Maxim Sobolev
sobomax at sippysoft.com
Tue Jan 12 06:32:56 CET 2016
Hi Bogdan, please drop me a note if possible when you merge that patch
into public branch[es], I'll adjust my test case to verify that
accordingly.
On the second issue, it basically about handling of INVITE
transactions in the tm module. The issue is that given unique, new
INVITE transaction those two pieces of routing code would behave
differently as viewed by the remote UAC:
[---routing 1---]
## shield us against retransmits
if (!t_newtran()) {
sl_reply_error();
exit;
};
t_relay("udp:X.Y.Z.W:5060");
[---end routing 1---]
[---routing 2---]
t_relay("udp:X.Y.Z.W:5060");
[---end routing 2---]
The first one won't generate "100 Trying", while the second would. I
don't think the "udp:X.Y.Z.W:5060" is of any importantce, it would
probably be the same with just bare t_relay(), but that's what I've
been testing with. I had to add the following workaround to get it
working properly:
if (!t_newtran()) {
sl_reply_error();
exit;
};
+ if (method == "INVITE") {
+ t_reply("100", "Trying");
+ };
I don't think this is intended behavior. The easy fix would be to
patch the t_relay(), but in fact I think 100 Trying should be
generated by the t_newtran() in that case. This would cause UAC to
stop retransmits and let opensips to work on the reply in peace.
On Mon, Jan 11, 2016 at 3:27 AM, Bogdan-Andrei Iancu
<bogdan at opensips.org> wrote:
> 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
>>
>>
>>
>
--
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