[asterisk-bugs] [Asterisk 0016295]: [patch] handle_incoming() incorrectly sets p->method to SIP_ACK

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16295 
====================================================================== 
Reported By:                omolenkamp
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   16295
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Target Version:             1.6.1.13
Asterisk Version:           SVN 
JIRA:                       SWP-452 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-11-20 14:43 CST
Last Modified:              2009-12-22 11:00 CST
====================================================================== 
Summary:                    [patch] handle_incoming() incorrectly sets p->method
to SIP_ACK
Description: 
When handle_incoming() in chan_sip.c processes an ACK packet, it will set
p->method to SIP_ACK (line 20567 in 1.6.1.10), just like it does for other
types of packets. In case of an ACK, this doesn't seem right, as the field
is supposed to contain the "SIP method that opened this dialog".

In specific cases, this can also lead to actual problems. An example of
this is the following conversation for setting up a call by a device that
needs to authenticate:

1. in:  INVITE (CSeq 1)
2. out: 401 Unauthorized (CSeq 1)
3. out: 401 Unauthorized (CSeq 1 - retransmission)
4. in:  ACK (CSeq 1)
5. in:  INVITE (CSeq 2)
6. out: 100 Trying (CSeq 2)
7. in:  ACK (CSeq 1)
8. out: 100 Trying (CSeq 2)
...

Both after packet 4 and 7, p->method will be changed to SIP_ACK. The first
time, this doesn't cause any problems as the following packet 5 will set it
to SIP_INVITE again, but after packet 7 (caused by the retransmission of
packet 2) that isn't even fully processed because of its CSeq, it does:

During the transmission of the following packets (100, ..., 200) p->method
will still be set to SIP_ACK, which results in the omission of some
headers, some of which are mandatory. ("Contact" in the "200 OK" for
example, usually added by respprep() if resp_needs_contact() tells it to)

The missing Contact-header will then cause some clients, like snom 370
phones, to send their ACK for the 200 directly to the server specified in
the To-header, instead of to Asterisk. Asterisk will then close the call
after a few seconds because it never receives the ACK.
====================================================================== 

---------------------------------------------------------------------- 
 (0115651) svnbot (reporter) - 2009-12-22 11:00
 https://issues.asterisk.org/view.php?id=16295#c115651 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 236063

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r236063 | dvossel | 2009-12-22 11:00:09 -0600 (Tue, 22 Dec 2009) | 18
lines

Merged revisions 236062 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r236062 | dvossel | 2009-12-22 10:58:19 -0600 (Tue, 22 Dec 2009) | 11
lines
  
  fixes issue with p->method incorrectly set to ACK
  
  It is possible for a second ACK to come in for a retransmitted message.
  If an ack does not match an unacked message in our queue, restore the
previous
  p->method as this ACK is completely ignored.
  
  (closes issue https://issues.asterisk.org/view.php?id=16295)
  Reported by: omolenkamp
  Patches:
        issue16295_v2.diff uploaded by dvossel (license 671)
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=236063 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-22 11:00 svnbot         Checkin                                      
2009-12-22 11:00 svnbot         Note Added: 0115651                          
======================================================================