Summary:	ASTERISK-14117: Behaviour when dealing with Diversion that leads back to Asterisk
Reporter:	Örn Arnarson (orn)	Labels:
Date Opened:	2009-05-13 06:17:27	Date Closed:	2011-07-26 14:19:23
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) fwddebug.txt
Description:	I am using Asterisk as an SMG with a Sangoma A104D card and their WOOMERA channel. I am running Debian Etch, Linux smg01.muli 2.6.18-6-686-bigmem #1 SMP Fri Dec 12 17:49:59 UTC 2008 i686 GNU/Linux I have run into a problem (which I believe occurs in app_dial) when an INVITE comes in from the PSTN, through the Asterisk, to a SIP proxy (Kamailio), that SIP proxy has unconditional diversion of the B-number to a number on the PSTN and therefore adds a Diversion header and sends a new INVITE to the Asterisk to be put back out to the PSTN. The problem is threefold: 1) When the Asterisk receives the INVITE with Diversion set from the proxy, it sends a CANCEL to the SIP proxy, despite the proxy having inserted a Record-Route header. The proxy, therefore, has no information on the call for billing purposes, which would not be a major problem if 2) weren't the case. 2) For the new leg of the call, since it is diverted, Asterisk seems to believe it should not be billed. The new call leg, therefore, always has 0 length in billsec. 3) If the diverted call coming in has more than one Diversion field, Asterisk chooses the oldest one instead of the newest one to set as the RDNIS. This is only the case if the call comes in through the Asterisk to begin with, i.e. if the call originates on the PSTN. If the call originates on the SIP proxy, goes through two diversions, and then to the PSTN, Asterisk correctly chooses the most recent Diversion number as the RDNIS. The diversion fields are identical between the two call scenarios. Additionally, I would like to use information from the SIP headers in the Dial Plan, but as the CANCEL message is sent, there is no SIP channel for this call, which is problematic.
Comments:	By: Leif Madsen (lmadsen) 2009-09-18 09:32:43 per mmichelson: The first problem is due to some SIP spiraling behaviour in Asterisk. This is currently being worked on, so please keep an eye out for commits over the next 2-4 weeks regarding this. The second problem, not too sure about. The third problem, a more indepth review of the diversion draft needs to be done in order to determine if Asterisk is doing something incorrectly (in 1.4) By: Örn Arnarson (orn) 2010-09-27 08:44:07 Same behavior is observed without the Diversion tag -- if Asterisk sees an INVITE from the same SIP proxy it sent its original invite to with the same Call-ID, it'll send a CANCEL to said proxy, despite having a Record-Route header. By: Leif Madsen (lmadsen) 2010-10-04 12:25:21 I'd like to confirm you have re-tested with the latest 1.4 code? This issue is quite old now and just want to make sure we're all on the same page. By: Örn Arnarson (orn) 2010-10-04 12:54:01 Sorry, I attached this note to the wrong case I guess. I intended to attach this to the 1.6 thread; https://issues.asterisk.org/view.php?id=15994 I'm not sure whether or not the behavior I am observing is accidental or not (in fact, it seems to be intended), but I don't think it is the right behavior. Versions tested 1.6.1.11 and 1.6.2.9. By: Leif Madsen (lmadsen) 2011-07-26 14:19:18.747-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!