[Home]

Summary:ASTERISK-09980: SIP - ACK not processed, 200 OK retransmitted
Reporter:rudinsky (rudinsky)Labels:
Date Opened:2007-07-30 05:10:54Date Closed:2011-06-07 14:03:20
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) full
( 1) sip_capt.zip
( 2) sipOK-retransmit.pcap
( 3) sipOK-retransmit.png
Description:Making a SIP call over long-delay connection causes Asterisk to quit the session unexpectedly.

Jul 30 10:48:54 WARNING[24077]: chan_sip.c:1228 retrans_pkt: Maximum retries
exceeded on transmission NWZiNGViNTlhNGQ5ODFkNjQ0YzU0MmNmZTdkODRkMmM. for seqno 2 (Critical Response)
Jul 30 10:48:54 WARNING[24077]: chan_sip.c:1245 retrans_pkt: Hanging up call
NWZiNGViNTlhNGQ5ODFkNjQ0YzU0MmNmZTdkODRkMmM. - no reply to our critical packet.
Jul 30 10:48:54 WARNING[24103]: file.c:592 ast_readaudio_callback: Failed to write frame
 == Spawn extension (default, 334, 1) exited non-zero on 'SIP/honza-0819bd20'

Probably the ACK is not processed and Asterisk resends 200 OK response.

****** ADDITIONAL INFORMATION ******

Network delay between client and server: 1 000 ms
Asterisk: 1.2.22
System: Debian GNU/Linux 2.6.15-1-486
Comments:By: rudinsky (rudinsky) 2007-07-30 05:20:34

full:
Asterisk full log.

sip_capt.zip:
First short call was terminated by client after 10s. Signalling according to recom. The second call was unexpectedly quit at Asterisk after 20s and was then "terminated" by client after 30s. ACK seems not to be processed and 200 OK is being retransmitted.
By: John Todd (jtodd) 2007-08-30 12:50:16

Does this also occur in 1.4?
By: Emmanuel BUU (neutrino88) 2007-09-14 12:54:37

I had a similar situation where a SIP phone would initiate a new transaction BEFORE the ACK was sent:


SIP Phone                Asterisk

INVITE (CSEQ=1) ---------->

<------------------ 180 RINGING

<------------------ 200 OK

INFO (CSEQ=3) ---------->
<------------------ 200 OK

ACK CSEQ = 2 ------------> dropped

<------------------- 200 OK (CSEQ=2) restransmision

I designed a patch for 1.4.x branch

Index: channels/chan_sip.c
===================================================================
--- channels/chan_sip.c (révision 82392)
+++ channels/chan_sip.c (copie de travail)
@@ -14952,7 +14952,7 @@
       if (option_debug > 3)
               ast_log(LOG_DEBUG, "**** Received %s (%d) - Command in SIP %s\n", sip_methods[p->method].text, sip_methods[p->method].id, cmd);

-       if (p->icseq && (p->icseq > seqno)) {
+       if (p->icseq && (p->icseq > seqno) && req->method != SIP_ACK) {
               if (option_debug)
                       ast_log(LOG_DEBUG, "Ignoring too old SIP packet packet %d (expecting >= %d)\n", seqno, p->icseq);
               if (req->method != SIP_ACK)
By: Olle Johansson (oej) 2007-12-11 01:38:55.000-0600

Is this still an issue in 1.4? Please check with the latest 1.4 from svn. Thanks.
By: Tilghman Lesher (tilghman) 2007-12-28 16:50:25.000-0600

No response from reporter.
By: Leif Madsen (lmadsen) 2008-08-11 13:14:16

This issue has been re-opened by request of pjezek on #asterisk-bugs.
By: pj (pj) 2008-08-11 13:27:40

I looked at sip callflow in asterisk and seems, that asterisk retransmits SIP/OK, even in case that first SIP/OK was correctly ACKed by other party.
If you look at attached call graph analysis, you can see it,
also, asterisk delayed initial INVITE about 200ms, before it forwards to another party, why?
SVN-trunk-r136787
I must also notice, that my asterik server was 100% idle, only one call was processed, when this dump was taken. Call was over LAN connection.
uploaded:
sipOK-retransmit.pcap
sipOK-retransmit.png
By: pj (pj) 2008-08-11 13:45:56

I have suspiction, that this SIP/OK unnecessary retransmits starts appearing after removing 500ms delay in SIP/OK forwarding, see bugreport 0012708, at end, you can see callgraph here, where is 500ms delay of SIP/OK, but no SIP/OK retransmits.
By: pj (pj) 2008-08-11 15:25:50

after discussion with blitzrage on IRC, I made new bugreport ASTERISK-1320287 for my issue, because it have only similar symptoms, like here, but it's not directly related.
By: Leif Madsen (lmadsen) 2008-08-11 16:01:54

When speaking on IRC, I thought the issue pjezek had was due to the change in this bug, but upon further discussion that was not the case. He opened a new bug, and I have marked a relation between the two bugs, but will re-close this one. Discussion on his issue can happen in the new bug.

Thanks!