Re: [SR-Users] Kamailio consult CNAM server through SIP Subscribe.

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 <joseseabra4@gmail.com mailto:joseseabra4@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
<miconda@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