Hi Ben,

I just pushed the fix on git, it was areally stupid error.

Thanks for reporting,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Summit 2018
  http://www.opensips.org/events/Summit-2018Amsterdam

On 02/22/2018 03:18 PM, Ben Newlin wrote:

I saw this behavior in 2.3.2, 2.3.3, and I am now running on HEAD of the 2.3 branch.

Ben Newlin

*From: *Bogdan-Andrei Iancu <bog...@opensips.org>
*Date: *Thursday, February 22, 2018 at 5:20 AM
*To: *OpenSIPS users mailling list <users@lists.opensips.org>, Ben Newlin <ben.new...@genesys.com>
*Subject: *Re: [OpenSIPS-Users] del_uri_param failure

Hi Ben,

What OpensSIPS version and revision are you working with ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam

On 02/22/2018 01:07 AM, Ben Newlin wrote:

    Hi,

    I am very glad to have the new del_uri_param function. This was a
    common problem of mine and it is great not to have to use regex to
    do this. However, while implementing this I have run into some
    strange behavior by the function when the URI param being deleted
    does not exist.

    In my case I am using the dialog module and attempting to remove a
    URI param just after the dialog creation. When the function does
    not find the URI param, it causes the dialog to immediately be
    destroyed and all message processing stops, including exiting the
    script.

    Feb 21 22:47:42 [371] DBG:uri:del_uri_param: requested key not
    found in RURI

    Feb 21 22:47:42 [371] DBG:dialog:next_state_dlg: unref dlg
    0x7f460780a8c8 with 1 -> 2 in entry 0x7f46077fbfa8

    Feb 21 22:47:42 [371] DBG:core:evi_param_set: adding string param

    Feb 21 22:47:42 [371] DBG:core:evi_param_set: adding string param

    Feb 21 22:47:42 [371] DBG:core:evi_param_set: adding int param

    Feb 21 22:47:42 [371] DBG:core:evi_param_set: adding int param

    Feb 21 22:47:42 [371] DBG:core:destroy_avp_list: destroying list (nil)

    Feb 21 22:47:42 [371] DBG:dialog:next_state_dlg: dialog
    0x7f460780a8c8 changed from state 1 to state 5, due event 1

    Feb 21 22:47:42 [371] DBG:dialog:dlg_onreply: dialog
    0x7f460780a8c8 failed (negative reply)

    Feb 21 22:47:42 [371] DBG:dialog:unref_dlg: unref dlg
    0x7f460780a8c8 with 1 -> 1 in entry 0x7f46077fbfa8

    Feb 21 22:47:42 [371] DBG:dialog:unref_dlg: unref dlg
    0x7f460780a8c8 with 1 -> 0 in entry 0x7f46077fbfa8

    Feb 21 22:47:42 [371] DBG:dialog:unref_dlg: ref <=0 for dialog
    0x7f460780a8c8

    Feb 21 22:47:42 [371] DBG:dialog:destroy_dlg: destroying dialog
    0x7f460780a8c8

    Feb 21 22:47:42 [371] DBG:dialog:destroy_dlg: dlg expired or not
    in list - dlg 0x7f460780a8c8 [3710:1818203549] with clid
    '2-185@127.0.0.1<mailto:2-185@127.0.0.1>' and tags '185SIPpTag002'
    'NULL'

    Feb 21 22:47:42 [371] DBG:core:destroy_avp_list: destroying list
    0x7f460780c048

    Feb 21 22:47:42 [371] DBG:core:receive_msg: cleaning up

    The logs indicate that a DLG_EVENT_TDEL is being raised which,
    when the dialog is still in UNCONFIRMED state, causes the dialog
    to be destroyed. It’s not clear to me how or why the del_uri_param
    function could be doing this, especially as a transaction hasn’t
    even been created for the message yet in this case. I’m not sure
    what effect this would have if the dialog is in other states or at
    other times during the call.

    It took me a while to realize it was the del_uri_param function
    causing this, as it seems so strange. But I have verified that
    when I remove the function, or when I verify the URI param exists
    before calling the function, everything is fine. That workaround
    works perfectly well, but it seemed such strange and catastrophic
    error behavior to drop the entire message that I wanted to report
    it anyway to see if anything needed to be addressed.

    Call traces can be found here: https://pastebin.com/9FnmJCD9

    You will see the same INVITE is offered multiple times as OpenSIPS
    is not responding after dropping the previous requests and dialog.

    Thanks,

    Ben Newlin




    _______________________________________________

    Users mailing list

    Users@lists.opensips.org<mailto:Users@lists.opensips.org>

    http://lists.opensips.org/cgi-bin/mailman/listinfo/users




_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to