[asterisk-bugs] [Asterisk 0015994]: Wrong handling of INVITE with Diversion tag when Asterisk has seen the callid before

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15994 
====================================================================== 
Reported By:                orn
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15994
Category:                   Channels/chan_sip/Transfers
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           Older 1.6.0 
JIRA:                       SWP-2325 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-09-30 14:18 CDT
Last Modified:              2010-10-06 06:23 CDT
====================================================================== 
Summary:                    Wrong handling of INVITE with Diversion tag when
Asterisk has seen the callid before
Description: 
Same scenario as 15095, but on 1.6 this time with very different (worse)
behaviour. Same hardware and operating system as that report.

When asterisk receives a call (via PSTN in this case), sends an INVITE to
a SIP proxy, that SIP proxy adds a Diversion tag and sends it back to
asterisk to get back to the PSTN, the call doesn't complete an asterisk
complains with a peculiar error:
[Sep 28 15:41:24] WARNING[32316]: chan_sip.c:4224 create_addr: No such
host: 5555555

5555555 is the number being forwarded to, and is nowhere specified as a
destination host.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015095 Behaviour when dealing with Diversion t...
====================================================================== 

---------------------------------------------------------------------- 
 (0127736) schmidts (developer) - 2010-10-06 06:23
 https://issues.asterisk.org/view.php?id=15994#c127736 
---------------------------------------------------------------------- 
ok thank you, so 1.8 handles the diversion header better than 1.6, as
expacted.

i have talked to klaus darillion about this, how kamilio should handle
this and we are still not sure whom wrong handling this is. In his opinion
asterisk should handle all incoming invites as a new call but as i have
understood the RFC a invite should not sent directly back to its origin
server cause a proxy cannot create a new call, just forward it to another
server. So a 302 Reply would be much better for this instead of sending an
invite back to the origin.

i will talk to some other developers how asterisk "should" act in this
situation. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-10-06 06:23 schmidts       Note Added: 0127736                          
======================================================================