[OpenSIPS-Users] problem loading dialogs from dbtext

[Jeff Pyle]

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>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 Developerhttp://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>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 Developerhttp://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> 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/20131024/275c777d/attachment.htm>