Hi Jeff, Perfect, thank you for your support with reporting and testing.
Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 11/06/2013 12:58 AM, Jeff Pyle wrote: > Hi Bogdan, > > Confirmed, everything restores correctly now. Tested on 1.9 pulled > from git today. > > > - Jeff > > > > On Tue, Oct 29, 2013 at 2:34 PM, Bogdan-Andrei Iancu > <bog...@opensips.org <mailto:bog...@opensips.org>> wrote: > > Hi Jeff, > > I uploaded a fix on GIT (see > > https://github.com/OpenSIPS/opensips/commit/adfe53f29fb93fa6f003431aee76e57db65da62a). > Fix was pushed on all maintained branches, so please update your > code and give it a try - let me know if it works for you. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > > On 10/28/2013 07:42 PM, Bogdan-Andrei Iancu wrote: >> 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 >>> <bog...@opensips.org <mailto:bog...@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 >>>> <bog...@opensips.org <mailto:bog...@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 >>>>> <bog...@opensips.org <mailto:bog...@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 >>>>>> <jp...@fidelityvoice.com >>>>>> <mailto:jp...@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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org <mailto:Users@lists.opensips.org> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users