[OpenSIPS-Users] problem loading dialogs from dbtext
Bogdan-Andrei Iancu
bogdan at opensips.org
Thu Nov 7 11:53:55 CET 2013
Hi Jeff,
Perfect, thank you for your support with reporting and testing.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11/06/2013 12:58 AM, Jeff Pyle wrote:
> Hi Bogdan,
>
> Confirmed, everything restores correctly now. Tested on 1.9 pulled
> from git today.
>
>
> - Jeff
>
>
>
> On Tue, Oct 29, 2013 at 2:34 PM, Bogdan-Andrei Iancu
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
> Hi Jeff,
>
> I uploaded a fix on GIT (see
> https://github.com/OpenSIPS/opensips/commit/adfe53f29fb93fa6f003431aee76e57db65da62a).
> Fix was pushed on all maintained branches, so please update your
> code and give it a try - let me know if it works for you.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 10/28/2013 07:42 PM, Bogdan-Andrei Iancu wrote:
>> Hi Jeff,
>>
>> It seems to be a bug in the uac module, not related to the dbtext
>> module. I will work on a fix and let you know for testing.
>>
>> Thanks and regards,
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 10/24/2013 09:03 PM, Jeff Pyle wrote:
>>> Bogdan,
>>>
>>> In the 'vars' column of the dbtext file I have values that look
>>> appropriate for the replacements. vsf, vst, etc. I don't see a
>>> 'values' column.
>>>
>>>
>>> - Jeff
>>>
>>>
>>>
>>>
>>> On Thu, Oct 24, 2013 at 12:50 PM, Bogdan-Andrei Iancu
>>> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>>
>>> Hi Jeff,
>>>
>>> It should be restart-safe - the UAC module stores info into
>>> the dialog - when doing the restart, do you see in the DB
>>> any data in the values field for your dialog ?
>>>
>>> Best regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>> http://www.opensips-solutions.com
>>>
>>>
>>> On 10/24/2013 03:24 PM, Jeff Pyle wrote:
>>>> Hi Bogdan,
>>>>
>>>> I believe it's dialog-based. I call topology_hiding()
>>>> early on the initial INVITE. The replace functions happen
>>>> on the branch_routes, very late in the processing. The
>>>> topology_hiding() function establishes the dialog, no?
>>>>
>>>> Should the dialog-based version be restart-safe also?
>>>>
>>>>
>>>> - Jeff
>>>>
>>>>
>>>>
>>>> On Thu, Oct 24, 2013 at 4:08 AM, Bogdan-Andrei Iancu
>>>> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>>>
>>>> Hi Jeff,
>>>>
>>>> The TO and FROM replacements can be signalling based
>>>> (storing a cookie in RR hdr) or dialog based (storing
>>>> the values in the dialog). Which one is used depends on
>>>> the order of your ops - if you create the dialog before
>>>> the replacements, then the dialog support will be used.
>>>> How is it in your case ?
>>>>
>>>> The signaling based replacement is not affected by
>>>> restarts (as values are stored in RR/R hdr) - of
>>>> course, as time as sequential requests hit the
>>>> loose_route() stuff.
>>>>
>>>> Regards,
>>>>
>>>> Bogdan-Andrei Iancu
>>>> OpenSIPS Founder and Developer
>>>> http://www.opensips-solutions.com
>>>>
>>>>
>>>> On 10/24/2013 05:48 AM, Jeff Pyle wrote:
>>>>> Bogdan,
>>>>>
>>>>> Next problem... URI replacements don't carry through
>>>>> to in-dialog transactions if there is an Opensips
>>>>> restart during the dialog.
>>>>>
>>>>> I use uac_replace_to() and uac_replace_from() in
>>>>> branch_routes in my script. On a call with no restart
>>>>> between the INVITE and BYE transactions, all is well
>>>>> -- those functions make their replacements on the
>>>>> initial INVITE, and those replacements carry through
>>>>> to future in-dialog transactions (like a BYE). If I
>>>>> restart Opensips between the INVITE and the BYE, the
>>>>> BYE doesn't receive the replacements.
>>>>>
>>>>> In my particular case this causes upstream
>>>>> uac:replace_uri errors in an Opensips 1.6 system since
>>>>> the local and remote URIs for the dialog have changed.
>>>>>
>>>>> Let me know if you need any particular debugs or
>>>>> traffic captures.
>>>>>
>>>>>
>>>>> - Jeff
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Oct 23, 2013 at 11:30 AM, Bogdan-Andrei Iancu
>>>>> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>>>>
>>>>> Hi Jeff,
>>>>>
>>>>> Thanks for your input and help - I found and fixed
>>>>> the bug - the fix was tested and uploaded on GIT.
>>>>> Please put back the dialog table spec from the
>>>>> sources (with "long" definition to the dlg_id
>>>>> column) and give it a fresh start.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Bogdan-Andrei Iancu
>>>>> OpenSIPS Founder and Developer
>>>>> http://www.opensips-solutions.com
>>>>>
>>>>>
>>>>> On 10/22/2013 10:25 PM, Jeff Pyle wrote:
>>>>>> I think I've found part of it. On line 536 of
>>>>>> modules/db_text/dbt_file.c it reads 'bigint'.
>>>>>> 'bigint' is read as a blob; it seems 'long' is
>>>>>> the correct word to read the 'l' for DB_BIGINT
>>>>>> (line 198).
>>>>>>
>>>>>> Making that change helps, but now there is a new
>>>>>> problem:
>>>>>>
>>>>>> ERROR:dialog:load_dialog_info_from_db:
>>>>>> inconsistent hash data in the dialog
>>>>>> database: you may have restarted opensips
>>>>>> using a different hash_size: please erase
>>>>>> dialog database and restart
>>>>>> db : 869, dlg : 1919252015
>>>>>>
>>>>>>
>>>>>> Obviously 869 != 1919252015, but I haven't found
>>>>>> where those numbers come from. And the hash_size
>>>>>> hasn't actually changed. Line 565 of
>>>>>> modules/dialog/dbt_db_handler.c is the complainer.
>>>>>>
>>>>>> Perhaps another misbehaving column type in the
>>>>>> db_text table?
>>>>>>
>>>>>>
>>>>>> - Jeff
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 22, 2013 at 11:24 AM, Jeff Pyle
>>>>>> <jpyle at fidelityvoice.com
>>>>>> <mailto:jpyle at fidelityvoice.com>> wrote:
>>>>>>
>>>>>> Bogdan and team,
>>>>>>
>>>>>> This is on a 1.9 build from October 17, plus
>>>>>> the recently committed change to the dialog
>>>>>> table schema in dbtext.
>>>>>>
>>>>>> Here's the scenario... After a fresh
>>>>>> Opensips start, I place a call through it. A
>>>>>> dialog is established. I stop Opensips after
>>>>>> about five seconds and verify the contents of
>>>>>> the dialog table file:
>>>>>>
>>>>>> dlg_id(bigint) callid(string)
>>>>>> from_uri(string) from_tag(string)
>>>>>> to_uri(string) to_tag(string)
>>>>>> mangled_from_uri(string,null)
>>>>>> mangled_to_uri(string,null)
>>>>>> caller_cseq(string) callee_cseq(string)
>>>>>> caller_ping_cseq(int)
>>>>>> callee_ping_cseq(int)
>>>>>> caller_route_set(string,null)
>>>>>> callee_route_set(string,null)
>>>>>> caller_contact(string)
>>>>>> callee_contact(string)
>>>>>> caller_sock(string) callee_sock(string)
>>>>>> state(int) start_time(int) timeout(int)
>>>>>> vars(string,null) profiles(string,null)
>>>>>> script_flags(int) flags(int)
>>>>>> 8672076440446:662bbb7a-8f52-4c26-adaa-6f2f5f870751:.....remaining
>>>>>> fields for dialog record.....
>>>>>>
>>>>>>
>>>>>> I again start Opensips. I see this in the
>>>>>> log (debug=3):
>>>>>>
>>>>>> ERROR:dialog:load_dialog_info_from_db:
>>>>>> column dlg_id cannot be null/has wrong
>>>>>> type 6 -> skipping
>>>>>>
>>>>>>
>>>>>> One interesting note, when Opensips starts
>>>>>> the dlg_id column is defined with 'long'.
>>>>>> After Opensips exits, it has 'bigint' type.
>>>>>> I don't know if that's relevant.
>>>>>>
>>>>>>
>>>>>> - Jeff
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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/20131107/73dba0a3/attachment-0001.htm>
More information about the Users
mailing list