Summary:ASTERISK-12564: 200 OK retransmitted even when first SIP OK is ACKed
Reporter:pj (pj)Labels:
Date Opened:2008-08-11 15:20:50Date Closed:2008-09-08 20:38:35
Versions:Frequency of
Environment:Attachments:( 0) sipOK-retransmit.pcap
( 1) sipOK-retransmit.png
Description: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?

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.


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 in bugreport ASTERISK-1263708, where is 500ms delay of SIP/OK, but no SIP/OK retransmits.

this issue:
have similar symptoms like in bugreport ASTERISK-1027332
maybe related to bugreport ASTERISK-1263708

Comments:By: pj (pj) 2008-08-11 16:20:34

another possible relation to ASTERISK-1303115

By: pj (pj) 2008-08-22 06:36:41

after analyzing lot of packet captures, I can confirm, that '200 OK' retransmissions are caused by "could NOT get the channel lock" errors, as reported in ASTERISK-1303115

By: Digium Subversion (svnbot) 2008-09-08 20:38:31

Repository: asterisk
Revision: 141949

U   trunk/main/channel.c

r141949 | russell | 2008-09-08 20:38:31 -0500 (Mon, 08 Sep 2008) | 9 lines

Modify ast_answer() to not hold the channel lock while calling ast_safe_sleep()
or when calling ast_waitfor().  These are inappropriate times to hold the channel
lock.  This is what has caused "could not get the channel lock" messages from
chan_sip and has likely caused a negative impact on performance results of SIP
in Asterisk 1.6.  Thanks to file for pointing out this section of code.

(closes issue ASTERISK-12564)
(closes issue ASTERISK-12415)