[OpenSIPS-Users] problem loading dialogs from dbtext
Bogdan-Andrei Iancu
bogdan at opensips.org
Thu Oct 24 18:50:01 CEST 2013
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/20131024/f369e9a1/attachment-0001.htm>
More information about the Users
mailing list