[OpenSIPS-Users] problem loading dialogs from dbtext
Bogdan-Andrei Iancu
bogdan at opensips.org
Mon Oct 28 18:42:19 CET 2013
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
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20131028/fee54219/attachment-0001.htm>
More information about the Users
mailing list