[asterisk-bugs] [Asterisk 0017823]: [patch] A 'Directed pickup' call is later unable to Hold or Transfer

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17823 
====================================================================== 
Reported By:                alecdavis
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   17823
Category:                   Channels/chan_sip/Transfers
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     ready for testing
Target Version:             1.6.2.13
Asterisk Version:           SVN 
JIRA:                       SWP-2030 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!): 281467 
Request Review:              
====================================================================== 
Date Submitted:             2010-08-09 23:49 CDT
Last Modified:              2010-08-30 11:03 CDT
====================================================================== 
Summary:                    [patch] A 'Directed pickup' call is later unable to
Hold or Transfer
Description: 
Specifically: There is code to prevent an INVITE with Replaces: header
while on an existing call.

If notifycid=yes is enabled in sip.conf, after a call has been picked up
using directed pickup on an BLF button ('magic pickup' not the **extn
method), we are unable to place the call on Hold or to Transfer.

The call just gets dropped.
Asterisk sends "400 Bad request" to phone.

Hardware Grandstream GXP2000 and GXP2010 firmware 1.2.3.5

====================================================================== 

---------------------------------------------------------------------- 
 (0126433) dvossel (administrator) - 2010-08-30 11:03
 https://issues.asterisk.org/view.php?id=17823#c126433 
---------------------------------------------------------------------- 
I looked into this further and I don't know if this is something we should
fix.  Correct me if I am wrong but here is my understanding of the
situation.

1. The Grandstream is subscribing some device state.
2. The Grandstream gets a NOTIFY that the device is ringing which includes
the callid
3. Using the Grandstream's BLF button an INVITE with "Replaces" using the
callid
in the NOTIFY is sent to Asterisk indicating that Asterisk should replace
the ringing channel with this new one.

--- All is good up to here.

4. After the call is picked up, the Grandsteam attempts to put the call on
hold using the SIP specific Re-INVITE way of doing that.  The problem is
occurring with this Re-INVITE, for some reason it is including the same
"Replaces" header as the original INVITE that started the dialog. 
According to RFC 3891 if the "Replaces" header is present we are supposed
to try and honor it.  The patch you have up for review just disables
Asterisk from looking at the "Replaces" header when a channel is already
associated with the dialog, which does not seem like an RFC compliant way
of handling this.  Since we can't handle the "Replaces" header at that
point, terminating the dialog seems like the only option.

Does my analysis seem correct?  If so this seems like something that will
have to be solved on Grandstream's side rather than ours. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-30 11:03 dvossel        Note Added: 0126433                          
======================================================================