[OpenSIPS-Users] Error with Dialog module causing crash

[Ovidiu Sas]

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
<bogdan at voice-system.ro> 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
>> <bogdan at voice-system.ro> 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:number at ip T=sip:number at ip IP=ip
>>>>> ID=65851bfd-0fb0-43bc-a456-3c9ba5982828 at quadro.epygi-config.com 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
>>>>> d=65851bfd-0fb0-43bc-a456-3c9ba5982828 at quadro.epygi-config.com
>>>>> ;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
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>
>