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]>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 Developerhttp://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]>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
