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
