| Summary: | ASTERISK-12564: 200 OK retransmitted even when first SIP OK is ACKed | ||
| Reporter: | pj (pj) | Labels: | |
| Date Opened: | 2008-08-11 15:20:50 | Date Closed: | 2008-09-08 20:38:35 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| 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. ****** ADDITIONAL INFORMATION ****** 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) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=141949 | ||
