Hi Jeff, Jeff Pyle wrote: > Hi Bogdan, > > Ok. Is it safe to assume that this is "caused" by low network latency? not necessary...it might be because of long 200OK processing, like tracing in DB. > Do > you have any feel for how long the dialog module needs to process the 200? > it is not dialog module, but about other module doing work on the 200 OK. > I suppose that's not fair to ask because it would depend on machine speed. > no, it is not the machine, but the CFG. Anyhow this is more or less a bug in how the dialog state machine is updated. > Does this problem cause any problems with the actual operation of the dialog > module at this point? > not really (except the err logs) - your dialogs will be in "confirmed but not acknowledged" state but it is equivalent to "confirmed and acknowledged" state > With the restart... It's as if I just restarted it. No log data at debug=3. > I changed it to 6. There was just too much data for my mental parser to > deal with. I went to 4. By this point I couldn't make it restart anymore. > I have no idea what had changed. Perhaps it will reoccur and I can get more > data. We're going to be starting testing soon with the mi_datagram module; > perhaps if that causes the same issues I'll be able to get more data. > OK.
Regards, Bogdan > > - Jeff > > > > On 3/9/09 12:51 PM, "Bogdan-Andrei Iancu" <[email protected]> wrote: > > >> Hi Jeff, >> >> The error message translates in receiving the ACK before finishing >> processing the 200 OK....It is race I know about and I'm planing the fix it. >> >> In regards to "opensipsctl fifo dlg_list", by restart, you mean crash? >> does the log says something about? >> >> Thanks and regards, >> Bogdan >> >> Jeff Pyle wrote: >> >>> Hi Bogdan, >>> >>> I updated from svn and the dialog profile assignments seem to be behaving >>> now. >>> >>> However, I get this error: >>> >>> CRITICAL:dialog:log_next_state_dlg: bogus event 6 in state 2 for dlg >>> 0xb614953c [3865:384697978] with clid >>> '[email protected]' and tags 'as4156018e' '' >>> >>> It shows up when the call goes to 200 OK on the second PSTN carrier, after >>> failing on the first one, if that's relevant. >>> >>> The dialog still shows up in the database in the proper profile with the >>> proper value. >>> >>> I don't know if this is related, but until just a moment ago anytime I ran >>> "opensipsctl fifo dlg_list", Opensips would restart. I moved debug to 6, >>> then to 4, and then back to 3. And it didn't happen anymore. Odd. >>> >>> >>> - Jeff >>> >>> >>> >>> On 3/9/09 10:29 AM, "Bogdan-Andrei Iancu" <[email protected]> wrote: >>> >>> >>> >>>> Hi Jeff, >>>> >>>> Thank you for the report - there was a bug in the new code (when >>>> create_dialog() was added), but now it is fixed on SVN. >>>> >>>> Please update and test again with your initial configuration (see the >>>> email I sent to Brett). >>>> >>>> Regards, >>>> Bogdan >>>> >>>> Jeff Pyle wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I'm configuring Opensips' dialog module to keep count of the number of >>>>> calls >>>>> I have on each outbound PSTN carrier. Here's my thinking: >>>>> >>>>> In request route: >>>>> - create_dialog() on new INVITE >>>>> - select carrier >>>>> - set_dlg_profile() to assign to proper profile with this carrier's value >>>>> >>>>> In failure route: >>>>> - unset_dlg_profile() to remove from profile, since it failed >>>>> - send to original request route to select next carrier, assign profile, >>>>> etc >>>>> >>>>> When I run this, the first set_dlg_profile() works properly, but the >>>>> unset_dlg_profile() in the failure route logs: >>>>> >>>>> ERROR:dialog:unset_dlg_profile: dialog was not yet created - script error >>>>> ERROR:dialog:w_unset_dlg_profile: failed to unset profile >>>>> >>>>> All subsequent set/unset_dlg_profile give the same error. Does the dialog >>>>> somehow get destroyed when the failure_route is hit? Is it necessary to >>>>> create_dialog() each time the failure_route is hit by sending it back >>>>> around >>>>> to a request route? >>>>> >>>>> >>>>> Thanks, >>>>> Jeff >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected] >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> >>>>> >>> >>> > > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
