[asterisk-bugs] [JIRA] (ASTERISK-21310) __sip_xmit fails with interrupted system call

[Wolfgang Pichler (JIRA)]

Wolfgang Pichler created ASTERISK-21310:
-------------------------------------------

             Summary: __sip_xmit fails with interrupted system call
                 Key: ASTERISK-21310
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21310
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Channels/chan_sip/TCP-TLS
         Environment: centos 5.8, 32 bit
            Reporter: Wolfgang Pichler
            Severity: Minor


i do have a strange behaviour here - on my system i do get the following error(s) every 20 seconds - the problem does not seem to hurt something - but it seems strange - and maybe it will get problematic on higher volume...

the message(s) i get are

[Mar 20 08:50:08] WARNING[6116]: chan_sip.c:3395 __sip_xmit: sip_xmit of 0xb4b9a88 (len 497) to 91.118.23.149:1035 returned -2: Success
[Mar 20 08:50:27] WARNING[6116]: chan_sip.c:3395 __sip_xmit: sip_xmit of 0xa986d30 (len 497) to 91.118.23.149:1035 returned -2: Interrupted system call

I do have taken a look at __sip_xmit - in my case it is the tcp transport - so it does call sip_tcptls_write.

This function does set res = len at the begining - len is not -2...

This function does return the len - or XMIT_ERROR - i can not see anything where res could get an other value in this function - so - how is it possible that it does return -2 ?

Some side info - the message the system is trying to retransmit is a BYE message - sent to a device on a tcp transport - which i do have changed to a udp transport.

The data pointer is not always the same - it is the same for some messages - but now always. Also it does update the cseq field...

What i can see - is that when i get Interrupted system call - then it will update the cseq to the next cseq in an existing data structure - when it does return "Success" (with res==-2) - then it create a new data structure.

I can not find the real problem here - the workaround i can imagine is to check for res<0 in __sip_xmit instead of res==-1 - so that the retransmits does stop.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira