Summary:	ASTERISK-10836: Respect the original "From" header in "Dial" application
Reporter:	Iñaki Baz Castillo (ibc)	Labels:
Date Opened:	2007-11-20 05:57:49.000-0600	Date Closed:	2011-06-07 14:08:06
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
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@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@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.
Comments:	By: Iñaki Baz Castillo (ibc) 2007-11-20 06:18:38.000-0600 Of course, the "From" header should be respected just if both channels are SIP. By: Iñaki Baz Castillo (ibc) 2007-11-20 06:33:15.000-0600 I know Asterisk is not a SIP proxy, so what I said about "From header shouldn't be changed" it's not applicable here. Anyway I understand that it would be easy to respect the "From" header is both caller and called channels are SIP. It would avoid possible username@domain conflicts. By: Joshua C. Colp (jcolp) 2007-11-20 08:26:34.000-0600 In my opinion I consider this proper behavior, there are two separate SIP channels up one going phone -> asterisk and the other asterisk -> phone. I have assigned this to oej though for a final decision. By: Olle Johansson (oej) 2007-11-20 08:32:54.000-0600 Well, Asterisk is a multiprotocol b2bua, not a proxy. The domain is not handled in a good way in Asterisk and this needs a bit of redesign to be handled, something we've tried to do for a long time, but hasn't really been acted upon. So this is not really a bug, but a flaw in the current asterisk design where we can't handle the at sign (@) in a "number" so the domain is separated and can't be set in the caller ID on outbound calls. We propably could do a quick fix so that the incoming SIPDOMAIN channel variable could be used also for the outbound call, but that's rather ugly. By: Olle Johansson (oej) 2007-11-20 08:34:52.000-0600 The real interesting scenario is when we have an inbound SIP call from external domain being sent to another channel than SIP - how do we make sure the call can be returned? By: Iñaki Baz Castillo (ibc) 2007-11-20 08:36:09.000-0600 Just, they are two channels of course. But the username of the caller appears as From in the called channel, so they are two independent channels but there is info shared between them (not so independent them). The question is, why just share the username? In SIP world a username without domain is not enough information. Asterisk could easily respect From domain in those cases (both SIP channels). It just can be good :) By: Iñaki Baz Castillo (ibc) 2007-11-20 16:26:56.000-0600 > when we have an inbound SIP call from external domain being sent to another > channel than SIP - how do we make sure the call can be returned? IMHO there is not solution for that, of course. There is for now some protection when using PSTN because the incoming numbers are pre-defined (and others are just not allowed). In calls with a SIP channel and H323 channel there is not a good solution, of course. Handing domains maybe not possible for H323 (is it?), so if sip:200@domainA or sip:200@domainB calls Asterisk and a H323 channel is created (or any other not SIP), then there is no way to pass the domain info. But in SIP, sip:200@domainA is perfectly valid as sip:200@domainB is (and they are completely different). And Asterisk can easily respect the From domain. Would be very complex to add a test before creating a SIP channel? something like:  if (caller_channel == SIP && called_channel == SIP)    from_header = caller_from_header  else    from_header = ... XD Regards. By: Olle Johansson (oej) 2007-11-21 00:39:41.000-0600 Well, we are a multiprotocol PBX and try to look for solutions that work multiprotocol. We can't just proxy stuff through the SIP channel in a way that breaks the concept. I had a design for this that Kevin Fleming and I worked on a few years ago, let's see if I find it. By: Iñaki Baz Castillo (ibc) 2007-11-21 04:00:48.000-0600 > Well, we are a multiprotocol PBX and try to look for solutions that work > multiprotocol. We can't just proxy stuff through the SIP channel in a way > that breaks the concept. Sure, but let me insist a bit that passing the From domain (when possible) doesn't break this multiprotocol PBX concept. IMHO, in SIP channel the callerid is not the username, but the username@domain. Regards. By: Olle Johansson (oej) 2007-11-21 04:13:20.000-0600 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). By: Iñaki Baz Castillo (ibc) 2007-11-21 04:31:22.000-0600 Thanks for all your work. It would be really nice if what you mean in that presentation becomes real. People trying to do real SIP multidomain integration between OpenSer and Asterisk will thank you for that  ;) PD: Should this report remain open? By: Olle Johansson (oej) 2007-11-23 02:39:23.000-0600 Since we can read the From: header in the dialplan, we might want a quick fix while waiting for the architecture thing. I'm still thinking. By: Iñaki Baz Castillo (ibc) 2007-11-23 04:27:10.000-0600 Maybe an extension to CALLERID function?  CALLERID(domain)  CALLERID(user_domain) you would deserve a beer in Barcelona ;) By: Olle Johansson (oej) 2007-11-23 04:41:09.000-0600 Don't promise too much, I might run a class in Barcelona next spring :-) I just added a commit to svn trunk to change the internal caller ID structure http://svn.digium.com/view/asterisk/trunk/include/asterisk/channel.h?view=log then we can start changing some more functions and set outbound caller ID domain too. By: Iñaki Baz Castillo (ibc) 2007-11-23 05:04:41.000-0600 > Don't promise too much, I might run a class in Barcelona next spring :-) Yes, I know ;) Thanks for all. By: Olle Johansson (oej) 2007-11-27 01:23:34.000-0600 Started some work on this in the "calleridutf8" branch. By: Olle Johansson (oej) 2008-01-22 09:59:11.000-0600 Closing this for now. Continuing work on the branch and trying to find a long term fix for this issue. Thanks for your patience and support!