How will the UAC disconnect the call in this case (how it will be the BYE constructed)?
For now, I think the simple solution is to discard the dialog and maybe get a hook into the error_route. I don't think it's worth spending time in dealing with very broken clients (at least from a dialog pov). The dialog module is already complex enough and if we add more complexity for dealing with extremely broken clients doesn't make sense. I wonder if the broken 200ok was generated by a real UAS or a sipp script. Regards, Ovidiu Sas On Tue, Dec 16, 2008 at 11:34 AM, Bogdan-Andrei Iancu <[email protected]> wrote: > Hi Ovidiu, > > I agree it is a more sane approach to decline bogus traffic, but as we are a > proxy, you do not have full control over the call flow. Like in this case - > the call was accepted by UAS and we get a 200 OK without Contact - what to > do? > - continue monitoring a dialog without callee contact? > - discard the dialog, event if we cannot actually block the call (like > dropping 200 OK). > > Regards, > Bogdan > > Ovidiu Sas wrote: >> >> I think we should discard the dialog and print a warning into the syslog. >> Maybe a hook into the error_route would help for some extra actions >> (reject the call for instance). >> Also, maybe it's time to enforce the mandatory from tag on the initial >> INVITE (right now, the dialog module is forgiving with clients that >> are not sending from tag). >> >> Regards, >> Ovidiu Sas >> >> On Tue, Dec 16, 2008 at 10:51 AM, Bogdan-Andrei Iancu >> <[email protected]> wrote: >> >>> >>> Hi, >>> >>> it seams that the reply has no Contact header (see the error), so no >>> contact is stored into the dialog. Most probably the module tries later >>> to use the contact (on callee side) and it crashes.. >>> >>> Logical question - what do to if some dialog info is missing? continue >>> with a semi-bogus dialog or discard dialog? >>> >>> Regards, >>> Bogdan >>> >>> Dan Pascu wrote: >>> >>>> >>>> On Tuesday 16 December 2008, Andrew Yager wrote: >>>> >>>> >>>>> >>>>> Hi, >>>>> >>>>> I seem to be having an issue with the dialog module causing a crash in >>>>> OpenSIPS. >>>>> >>>>> The logs are reporting... >>>>> >>>>> Dec 16 16:14:28 softswitch1 /usr/sbin/opensips[11785]: Setting acc >>>>> destination-leg for uuid '<null>' - M=OPTIONS RURI=sip::5060 >>>>> F=sip:num...@ip T=sip:num...@ip IP=ip >>>>> [email protected] Dec 16 >>>>> 16:14:28 softswitch1 /usr/sbin/opensips[11783]: ACC: >>>>> transaction answered: >>>>> timestamp >>>>> = >>>>> 1229404468 >>>>> ;method >>>>> = >>>>> OPTIONS >>>>> ;from_tag=1227751938a7abcd7c-1632-4f29-86fa-0220998fc183;to_tag=;call_i >>>>> [email protected] >>>>> ;code=200;reason=OK >>>>> Dec 16 16:14:28 softswitch1 /usr/sbin/opensips[11783]: >>>>> ERROR:dialog:dlg_onreply: missing TAG param in TO hdr :-/ >>>>> Dec 16 16:14:28 softswitch1 /usr/sbin/opensips[11783]: >>>>> ERROR:dialog:populate_leg_info: bad sip message or missing Contact hdr >>>>> Dec 16 16:14:28 softswitch1 /usr/sbin/opensips[11783]: >>>>> ERROR:dialog:dlg_onreply: could not add further info to the dialog >>>>> Dec 16 16:14:28 softswitch1 /usr/sbin/opensips[11777]: >>>>> INFO:core:handle_sigs: child process 11783 exited by a signal 11 >>>>> Dec 16 16:14:28 softswitch1 /usr/sbin/opensips[11777]: >>>>> INFO:core:handle_sigs: core was not generated >>>>> Dec 16 16:14:28 softswitch1 /usr/sbin/opensips[11777]: >>>>> INFO:core:handle_sigs: terminating due to SIGCHLD >>>>> Dec 16 16:14:28 softswitch1 /usr/sbin/opensips[11778]: >>>>> INFO:core:sig_usr: signal 15 received >>>>> Dec 16 16:14:28 softswitch1 /usr/sbin/opensips[11779]: >>>>> INFO:core:sig_usr: signal 15 received >>>>> >>>>> Any suggestions? I can provide config if required. >>>>> >>>>> >>>> >>>> config is useless to debug this. a backtrace can help. >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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
