webrtc2sip sometimes freezes in the sense that it fails to process messages to its UDP-port

[GoogleCodeExporter]

Unfortunately not an easily reproducable problem, but after X hours of running 
fine, webrtc2sip sometimes enters a frozen state where it no longer processes 
messages from its UDP port.

When this happens, then obviously things that talk to this UDP port (such as 
our old asterisk) no longer works.

Our easiest test that seems to prove that webrtc2sip has entered this bad 
frozen state is running: 

echo "Hello" | nc -u 192.168.1.226 9060

(in which 192.168.1.226 and 9060 is the host and port of webrtc2sip as seen 
from netstat -tupan | grep webrtc2sip)

When webrtc2sip is working fine, then the console/log outputs

RECV:Hello
***ERROR: function: "tsip_message_parse()"
file: "src/parsers/tsip_parser_message.c"
line: "227"
MSG: Failed to parse SIP message:

as expected, but when webrtc2sip is in this frozen state, nothing happens 
whatsoever, as if the UDP socket was dead.

The only solution at this point is restarting webrtc2sip and everything works 
fine again.

I have not yet been able to determine exactly what causes this, but upon 
experimenting with sending sip messages to the UDP port, i noticed that 
webrtc2sip is very prone to crash if the sip-messages look bad: for example by 
sending the following:

OPTIONS sip:@192.168.1.226 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:43544;branch=z9hG4bK.484c0a6f;rport;alias
From: sip:sipsak@127.0.0.1:43544;tag=5ef9bfa7
To: sip:@192.168.1.226
Call-ID: 1593425831@127.0.0.1
CSeq: 1 OPTIONS
Contact: sip:sipsak@127.0.0.1:43544
Content-Length: 0
Max-Forwards: 70
User-Agent: sipsak 0.9.6
Accept: text/plain

send to: UDP:192.168.1.226:9060

by running:
[root@pbxdev ~]# sipsak -r "9060" -s "sip:@192.168.1.226" -vvv

but if I send sip:blabla@192.168.1.226 or sip:192.168.1.226 it doesnt crash

What steps will reproduce the problem?
TBD
What is the expected output? What do you see instead?
see above,

What version of the product are you using? On what operating system?
I upgraded to latest doubango and webrtc2sip revision 1 month ago. I'm using 
Fedora 20

Please provide any additional information below.

If you have any ideas what might be going on, feel free to give me some tips 
for tests I can do next time it gets frozen. It happens like once a week.

Original issue reported on code.google.com by StefanEn...@gmail.com on 20 Aug 2014 at 2:03

[GoogleCodeExporter]

I still don't know how to reliably produce this error, happens once a week at 
most, but if anyone else experienced something similar - my 'solution' was 
creating a watchdog which restarts the software when the UDP-socket seems dead. 
More specifically,
I modified tinySIP and added a cronjob which polls the socket with something 
like
echo "test" | nc <IP> <port>
and then if webrtc2sip is actually not frozen the new tinySIP will create a 
file, which cronjob then checks to see whether or not webrtc2sip is frozen.

Not a good solution though, and not recommended if UDP port is exposed to 
public internet, i guess... Anyways, the code change was just in 
tsip_parser_message.c 

tsk_bool_t tsip_message_parse(tsk_ragel_state_t *state, tsip_message_t 
**result, tsk_bool_t extract_content)
{
        if(!state || state->pe <= state->p){
                return tsk_false;
        }

        if(!*result){
                *result = tsip_message_create();
        }

        /* Ragel init */
        tsip_message_parser_init(state);

        /*
        *       State mechine execution.
        */
        tsip_message_parser_execute(state, *result, extract_content);

        /* Check result */

        if( state->cs <
/* #line 223 "./src/parsers/tsip_parser_message.c" */
37
/* #line 214 "./ragel/tsip_parser_message.rl" */
 )
        {
                //IF result contains WX3
                //touch file /var/run/webrtc2sipisalive
                FILE *pFile = fopen("/var/run/webrtc2sipisalive", "ab+");
                if (pFile!=NULL)
                {
                        //fputs ("fopen example",pFile);
                        fclose (pFile);
                }
                //
                //ELSE:
                //TSK_DEBUG_ERROR("Failed to parse SIP message: %s", state->p);
                TSK_OBJECT_SAFE_FREE(*result);
                return tsk_false;
        }
        return tsk_true;
}

Original comment by StefanEn...@gmail.com on 15 Sep 2014 at 7:44