[OpenSIPS-Users] problem loading dialogs from dbtext

[Jeff Pyle]

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>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 Developerhttp://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>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
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20131023/dece5713/attachment-0001.htm>