[OpenSIPS-Users] del_uri_param failure

[Bogdan-Andrei Iancu]

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 <bogdan at opensips.org>
> *Date: *Thursday, February 22, 2018 at 5:20 AM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>, Ben 
> Newlin <Ben.Newlin at 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 at 127.0.0.1<mailto:2-185 at 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 at lists.opensips.org<mailto:Users at lists.opensips.org>
>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180222/5c2072ec/attachment-0001.html>