[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:                     confirmed
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:              
====================================================================== 
Date Submitted:             2009-11-20 14:43 CST
Last Modified:              2009-12-08 11:05 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0114922) dvossel (administrator) - 2009-12-08 11:05
 https://issues.asterisk.org/view.php?id=16295#c114922 
---------------------------------------------------------------------- 
I don't understand why we set p->method there at all. We do it in
sip_alloc, why would we ever need to do it again?  The patch I uploaded is
the same as your's except without the p->method being set in
handle_incoming(). 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-08 11:05 dvossel        Note Added: 0114922                          
======================================================================