[asterisk-bugs] [Asterisk 0015095]: Behaviour when dealing with Diversion that leads back to Asterisk

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15095 
====================================================================== 
Reported By:                orn
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15095
Category:                   Applications/app_dial
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.23 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-05-13 06:17 CDT
Last Modified:              2010-10-04 12:25 CDT
====================================================================== 
Summary:                    Behaviour when dealing with Diversion that leads
back to Asterisk
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
https://issues.asterisk.org/view.php?id=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.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015994 Wrong handling of INVITE with Diversion...
====================================================================== 

---------------------------------------------------------------------- 
 (0127664) lmadsen (administrator) - 2010-10-04 12:25
 https://issues.asterisk.org/view.php?id=15095#c127664 
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-10-04 12:25 lmadsen        Note Added: 0127664                          
======================================================================