Summary:	ASTERISK-03973: [patch] Display Names in SIP To: headers
Reporter:	kimo_sabe (kimo_sabe)	Labels:
Date Opened:	2005-04-22 19:06:59	Date Closed:	2011-06-07 14:04:49
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	The Zultus ZIP4x4 displays the "Display name" part of the To: header for incoming calls so it would be nice if chan_sip had a way to set them.  It would be rather nice to be able to tell how a call came to ring the phone as well as who. I hacked chan_sip.c:initreqprep() to include a static string just for testing sake and got the desired result on the phone.  I also skimmed RFC3261 and it seemd to suggest that a display name is valid in the To: header. ****** ADDITIONAL INFORMATION ****** The BudgeTone 102 we have around didn't choke on the extra info, but didn't display it.
Comments:	By: nick (nick) 2005-04-22 19:25:33 Where should we get the To: name from? By: nick (nick) 2005-04-24 21:19:56 Here's a twofer patch: First, this uses the SIP_TONAME variable to set the To: name. So you can just do: exten => 1000,1,SetVar(SIP_TONAME=John) exten => 1000,2,Dial(SIP/1234) Second, this now copies all channel variables to the temporary channel that app_dial makes so that the channel driver can do stuff like this. I don't think this will break anything, but I'm not positive about that ;). kimo_sabe, please test this to make sure the name does show up in the To: field. I just hacked this based on what you said. My D is on F. Nick By: kimo_sabe (kimo_sabe) 2005-04-25 11:08:55 You're my hero, except I do see the patch attached to the bug. By: nick (nick) 2005-04-25 18:27:08 Attaching the patch might help! Whoops... Nick By: Olle Johansson (oej) 2005-04-26 15:23:48 While this is cool, I wonder if we can make this less channel specific? And I don't really like passing arguments to apps in channel variables... This is really about setting, hmmm, callee ID name (not caller ID name) on the outbound call leg. Does any other channel support this? If so, we should possibly make it an argument to dial() - set callee name. Variables for the second call leg should be named with an underscore as the first character to be consistent with current syntax. You should *not* change app_dial as suggested, it will cause other problems. All variables with an _ as the first character will be copied to the second call leg. Also, nick, we need to know if this code is disclaimed. By: Kevin P. Fleming (kpfleming) 2005-04-26 20:50:36 I don't see how this makes any sense at all... are you saying that a 4x4 phone being sent an INVITE displays the name from the To: header? That's completely borked, if so, because that name is the name of the phone the call is being sent to, not the caller. Am I just misunderstanding this? By: nick (nick) 2005-04-26 21:31:00 It displays who it is being sent to along with who the call is coming from, I think. I could see this being useful if you had, for example, people who were members of different queues who could then see who the call was going to and coming from. Should we extend the ast_callerid structure for this kind of data? Nick By: Kevin P. Fleming (kpfleming) 2005-04-26 22:17:49 I have had a design in mind for a rework of ast_callerid, but it's a long way off from happening. I don't think there is a better option than setting a channel variable with the desired value and letting chan_sip (or any other channel) process it... I'd suggest CALLEDIDNAME, though, so that if we do support COLP/COLN in the future, we'll be able to use the same variable name. By: Mark Spencer (markster) 2005-04-26 23:24:22 This can be done as SetVar(_SIP_TO_NAME=foo), that seems reasonable. By: kimo_sabe (kimo_sabe) 2005-05-18 17:32:04 The patch escaped before I had a chance to try it out. By: Kevin P. Fleming (kpfleming) 2005-05-19 00:29:57 Sorry, what does that mean? :-) Are you still working on this? By: Michael Jerris (mikej) 2005-06-19 10:38:49 It seems that no one is willing to work on this.  Please continue this bug by placing a bounty on the wiki or contracting the work.  See a bug marshall in #asterisk-bugs on IRC or open a new bug when there is code to review.   Thanks.