[OpenSIPS-Devel] No 100 Trying reply generated by the t_relay() for INVITE after t_newrean() [was: "Early cancel" issue..]
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Jan 12 10:03:05 CET 2016
Hi Maxim,
Yes, indeed, it is inconsistent, for historical reasons.
IMO, what needs to be decided is who should be in charge of generating
the 100 Trying:
- the user, manually, from script (via send_reply() )
- the code, automatically from inner functions.
Now we have a mixture. Each approach has its advantages. For manual 100
reply the user may decide what's the best place to start fighting
against retransmissions (and do the 100 reply), for what kind of traffic
to do it (calls, messages, presence), etc...It is more flexible, but
requires more SIP knowledge
The second approach (automatic 100 reply) may be simpler for the user
perspective, but raises a second level of questions:
- when to do the replying ( via t_newtran() ? via t_relay() ? )
- if it should be stateful or stateless (if stateful, doing 100
reply will force building the transaction much ahead in the script and
this will have some sides effects in versions before 1.11).
Thanks and Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 12.01.2016 07:32, Maxim Sobolev wrote:
> 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
>>>
>>>
>
>
More information about the Devel
mailing list