Hello,
Thanks for the hint to use cherry-pick,
After applying these two patches the issue seems to be fixed.
Please find out the attachment with kamailio logs.
Thank you for your help.
Regards
José
2016-06-21 10:41 GMT+01:00 Daniel-Constantin Mierla <mico...@gmail.com>:
> Hello,
>
> you should cherry-pick them with git into the branch 4.4.
>
> Cheers,
> Daniel
>
> On 21/06/16 11:04, José Seabra wrote:
>
> Hi Daniel,
> I have applied your last two patchs on tm module but i can't compile the
> module because kemi framwork.
>
> I'm using kamailio version 4.4.
>
> Compile Errors:
>
> t_fwd.c:61:24: error: ../../kemi.h: No such file or directory
> t_fwd.c: In function ‘prepare_new_uac’:
> t_fwd.c:157: error: ‘sr_kemi_eng_t’ undeclared (first use in this function)
> t_fwd.c:157: error: (Each undeclared identifier is reported only once
> t_fwd.c:157: error: for each function it appears in.)
> t_fwd.c:157: error: ‘keng’ undeclared (first use in this function)
> t_fwd.c:346: warning: implicit declaration of function ‘sr_kemi_eng_get’
> t_fwd.c:348: warning: implicit declaration of function
> ‘sr_kemi_act_ctx_get’
> t_fwd.c:348: warning: assignment makes pointer from integer without a cast
> t_fwd.c:350: warning: implicit declaration of function
> ‘sr_kemi_act_ctx_set’
> t_fwd.c:352: warning: implicit declaration of function
> ‘sr_kemi_cbname_lookup_idx’
> t_fwd.c: In function ‘add_blind_uac’:
> t_fwd.c:715: error: ‘TM_UAC_FLAG_BLIND’ undeclared (first use in this
> function)
> make: *** [t_fwd.o] Error 1
>
> Regards
> José
>
>
> 2016-06-21 9:38 GMT+01:00 José Seabra <joseseab...@gmail.com>:
>
>> Hello Daniel,
>>
>> I confirm that the phone receives 200 OK to the CANCEL and 487 to the
>> INVITE.
>>
>> I will backport the tm module to the last two patchs, then, after make
>> all tests I will report back to you.
>>
>> Regards
>> José
>>
>> 2016-06-21 5:33 GMT+01:00 Daniel-Constantin Mierla < <mico...@gmail.com>
>> mico...@gmail.com>:
>>
>>> Can you try with master branch or backport the last two patches from tm
>>> module? I pushed two commits that should catch and handle better this case.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 20/06/16 18:14, Daniel-Constantin Mierla wrote:
>>>
>>> Hello,
>>>
>>> it seems it tries to generate an outgoing cancel for the suspended
>>> branch. I will check the code, likely there has to be added condition for
>>> this cases.
>>>
>>> Is the 487 reply for invite sent back? Also, the 200ok for cancel?
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 20/06/16 16:38, José Seabra wrote:
>>>
>>> Hello,
>>>
>>> I'm attaching more logs to this email regarding to the issue on SIP
>>> CANCEL to an INVITE that is suspended.
>>>
>>> If do you think that i should open an issue on git regarding to this let
>>> me know.
>>>
>>> Thank you for your help.
>>>
>>> Best Regards
>>> José
>>>
>>> 2016-06-15 14:42 GMT+01:00 José Seabra < <joseseab...@gmail.com>
>>> joseseab...@gmail.com>:
>>>
>>>> Hi Daniel,
>>>>
>>>> But when Kamailio receives a CANCEL prints the following error messages:
>>>>
>>>> 2016-06-15 14:39:10.354 ERROR: tm [t_msgbuilder.c:287]:
>>>> build_local_reparse(): ERROR: build_local_reparse: INVITE is missing
>>>> 2016-06-15 14:39:10.354 ERROR: tm [t_msgbuilder.c:494]:
>>>> build_local_reparse(): ERROR: build_local_reparse: cannot build CANCEL
>>>> request
>>>> 2016-06-15 14:39:10.354 ERROR: tm [t_cancel.c:310]: cancel_branch():
>>>> ERROR: attempt to build a CANCEL failed
>>>> 2016-06-15 14:39:10.354 ERROR: tm [t_fwd.c:1389]: e2e_cancel(): ERROR:
>>>> cancel error
>>>>
>>>> I'm handling the CANCEL in the script by the following way:
>>>>
>>>>
>>>> if (is_method("CANCEL")) {
>>>> if (t_check_trans()) {
>>>> route(RELAY);
>>>> } else {
>>>> sl_send_reply("481", "Call leg/transaction does
>>>> not exist");
>>>> }
>>>> exit();
>>>> ...
>>>> ...
>>>> ...
>>>>
>>>> Thank you for your support.
>>>>
>>>> Regards
>>>> José
>>>>
>>>>
>>>> 2016-06-15 12:15 GMT+01:00 Daniel-Constantin Mierla <
>>>> <mico...@gmail.com>mico...@gmail.com>:
>>>>
>>>>> Hello,
>>>>>
>>>>> On 14/06/16 16:33, José Seabra wrote:
>>>>>
>>>>> Hi Olle and Daniel,
>>>>> Thank you for your replies, After receive your msg I looked again to
>>>>> my script and i found the problem.
>>>>>
>>>>> I didn't configure the correct failure_route block and the failure
>>>>> route configured didn't print any msg on the logs, so I thought that
>>>>> it wasn't entering on failure route.
>>>>>
>>>>> Sorry for my mistake.
>>>>>
>>>>> Anyway, How should i handle the CANCEL sip msg to an INVITE that is
>>>>> suspended? (still related with this implementation)
>>>>>
>>>>> Just handling it as done in the default configuration file is ok --
>>>>> the suspended transaction will be canceled.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>
>>> --
>>> Daniel-Constantin Mierlahttp://www.asipto.com -
>>> http://www.kamailio.orghttp://twitter.com/#!/miconda -
>>> http://www.linkedin.com/in/miconda
>>>
>>>
>>
>>
>> --
>> Cumprimentos
>> José Seabra
>>
>
>
>
> --
> Cumprimentos
> José Seabra
>
>
> --
> Daniel-Constantin Mierlahttp://www.asipto.com -
> http://www.kamailio.orghttp://twitter.com/#!/miconda -
> http://www.linkedin.com/in/miconda
>
>
--
Cumprimentos
José Seabra
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
