Summary:	ASTERISK-21310: __sip_xmit fails with interrupted system call
Reporter:	Wolfgang Pichler (wuwu)	Labels:
Date Opened:	2013-03-22 02:07:35	Date Closed:	2013-04-22 09:24:45
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/TCP-TLS
Versions:		Frequency of Occurrence	Constant
Related Issues:
Environment:	centos 5.8, 32 bit	Attachments:
Description:	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.
Comments:	By: Rusty Newton (rnewton) 2013-03-29 09:39:08.210-0500 Even if this WARNING wasn't an issue, it should probably be a DEBUG message and not a WARNING. A dev would need to investigate this to see whats going on. Can you please provide instructions on how to reproduce the scenario where the message occurs? Please provide the relevant configs (sip.conf at least) an Asterisk log with VERBOSE and DEBUG enabled as wel (turned up to level 5 each) and a PCAP of the traffic for the call related to the message. By: Rusty Newton (rnewton) 2013-04-22 09:24:37.609-0500 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines