[asterisk-bugs] [Asterisk 0018633]: asterisk does not respond with ACK on retransmission of 200 OK after it sent ACK

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18633 
====================================================================== 
Reported By:                rrevels
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18633
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           Older 1.6.2 - please test a newer version 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-01-17 09:31 CST
Last Modified:              2011-02-16 15:50 CST
====================================================================== 
Summary:                    asterisk does not respond with ACK on retransmission
of 200 OK after it sent ACK
Description: 
Upstream blocking causes the first ACK to be dropped before hitting
destination.  Retransmitted 200s show up in network trace on Asterisk
server but no ACK response is ever generated
====================================================================== 

---------------------------------------------------------------------- 
 (0132050) lmadsen (administrator) - 2011-02-16 15:50
 https://issues.asterisk.org/view.php?id=18633#c132050 
---------------------------------------------------------------------- 
rrevels: OK, so you have told us what version this isn't a problem on, but
have not told us what version this *is* a problem on. You've marked this as
an older version of 1.6.2, and said more recent versions do not exhibit
this problem.

Additionally I do see Asterisk respond to the 200 OK with an ACK in your
message:



<--- SIP read from UDP:216.27.87.216:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP
208.44.174.45:5060;received=208.44.174.45;branch=z9hG4bK56604b66;rport=5060
Record-Route: <sip:216.27.87.216;lr;ftag=as10f5522b>
From: "JOE" <sip:9194397461 at 208.44.174.45>;tag=as10f5522b
To: <sip:+19197023718 at 216.27.87.216>;tag=_2462058652-1042412449
Call-ID: 70580fae265510cb21ccfd2430e8ed5b at 208.44.174.45
CSeq: 102 INVITE
Contact: sip:+19197023718 at 12.34.5.94:5060
Accept: application/sdp
Allow: INVITE,ACK,CANCEL,BYE,INFO,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE
Content-Disposition: session; handling=required
Content-Type: application/sdp
Content-Length: 229

v=0
o=305419896 305419896 IN IP4 12.34.5.125
s=-
c=IN IP4 12.34.5.125
t=0 0
m=audio 15632 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=maxptime:40
a=sendrecv

<------------->
--- (13 headers 12 lines) ---
list_route: hop: <sip:216.27.87.216;lr;ftag=as10f5522b>
set_destination: Parsing <sip:216.27.87.216;lr;ftag=as10f5522b> for
address/port to send to
set_destination: set destination to 216.27.87.216, port 5060
Transmitting (no NAT) to 216.27.87.216:5060:
ACK sip:+19197023718 at 12.34.5.94:5060 SIP/2.0
Via: SIP/2.0/UDP 208.44.174.45:5060;branch=z9hG4bK30148e3c;rport
Route: <sip:216.27.87.216;lr;ftag=as10f5522b>
Max-Forwards: 70
From: "JOE" <sip:9194397461 at 208.44.174.45>;tag=as10f5522b
To: <sip:+19197023718 at 216.27.87.216>;tag=_2462058652-1042412449
Contact: <sip:9194397461 at 208.44.174.45>
Call-ID: 70580fae265510cb21ccfd2430e8ed5b at 208.44.174.45
CSeq: 102 ACK
User-Agent: providerVoice
Remote-Party-ID: "JOE"
<sip:9194397461 at 208.44.174.45>;privacy=off;screen=no
Content-Length: 0




To me this looks like either Asterisk isn't sending the response to the
right spot, or that the other end is behind NAT or something. NAT is
typically when I see this type of behaviour. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-02-16 15:50 lmadsen        Note Added: 0132050                          
======================================================================