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 > <[email protected] <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>>> <[email protected] >>>> <mailto:[email protected]>> 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 [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
