[asterisk-bugs] [Asterisk 0011322]: Respect the original "From" header in "Dial" application

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11322 
====================================================================== 
Reported By:                ibc
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   11322
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.14  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             11-20-2007 05:57 CST
Last Modified:              11-21-2007 04:13 CST
====================================================================== 
Summary:                    Respect the original "From" header in "Dial"
application
Description: 
If Asterisk receives an incoming SIP call from an **external** SIP account,
and during the dialplan it must call to an internal SIP user, the INVITE
from Asterisk has a modified "From" header (the fromdomain is changed by
Asterisk). Why?

This is not needed and it's very anti-RFC ("From" shouldn't be changed).

And in fact it can cause problems, as this example:

- Our Asterisk domain is "asterisk_domain.org".

- We have two internal users:
  - "Bob" <200>
  - "Pepe" <201>

- We receive an external SIP incoming call with this From header:
  From: "EXTERNAL <sip:201 at external_domain.com>"

- During the dialplan Asterisk finally does:
  Dial(SIP/200)

- This new INVITE generated by Asterisk will contain this header:
  From: "EXTERNAL" <sip:201 at asterisk_domain.org>   <--- DOMAIN CHANGED
!!!!


So our internal user "Bob" <200> will receive a call and will think that
it's a call from our internal user "Pepe" <201>. If, for example, the call
is not answered and later Bob open him "missed calls" he will see a call
from 201, and if he calls he will call in fact to "Pepe <201>".

This is IMHO a wrong behaviour. Asterisk shoudn't change the "From"
header, there is no reason for that. Why a internal user can't know from
which domain he recives a call vía Asterisk?

For the established dialog the "From" domain is not important at all, the
only the called needs to know if the Call-ID, From/To tags and Contact
header to send in-dialog requests, no more.

I attach a debug example that shows how the "From" header is changed in
the INVITE generated by Asterisk.
====================================================================== 

---------------------------------------------------------------------- 
 oej - 11-21-07 04:13  
---------------------------------------------------------------------- 
I agree with you, but Asterisk has a different opinion in the way it
handles URI's. I've been working with this project for many years to change
the SIP support step by step, implementing domain support in the SIP
channel and much more. But you still can't make changes in the SIP channel
that isn't part of the core architecture and add special functionality in
SIP that breaks other channels. We need to make this happen in the smart
way.

In the mean time I'm sure you can produce a patch to fix this on SIP2SIP
calls in Asterisk. That's easy. But it won't be integrated into the core
unless we create a better cross-channel solution.

BTW, just found this presentation
http://edvina.net/asterisk/alphanumericextensions.pdf
that I made in 2005 to provoke some changes that would make it possible to
accept full URI's as extensions in the dialplan... (there's a discussion on
the asterisk-dev mailing list now). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-21-07 04:13  oej            Note Added: 0074128                          
======================================================================