[Home]

Summary:ASTERISK-13345: [patch] Not possible to disguise display name on calls to trunks even though user can be disguised
Reporter:nick_lewis (nick_lewis)Labels:
Date Opened:2009-01-12 10:14:43.000-0600Date Closed:2009-01-13 10:18:37.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.c-displayname.patch
Description:When calling from an extension on the asterisk PBX to a trunk the sip display-name that is received in the invite from the extension is used as the display-name in the invite sent to the ITSP.

For example:
From: "John Smith" <sip:101@mypbx>
is converted to:
From: "John Smith" <sip:voipaccount@myitsp>
but it would be useful if it could be converted instead to:
From: "My Corporation" <sip:voipaccount@myitsp>
so that outgoing calls do not reveal the caller name
Comments:By: nick_lewis (nick_lewis) 2009-01-12 10:17:58.000-0600

Please find attached a patch that adds the fromname configuration parameter. If present on a trunk this parameter determines the display-name that is used for outgoing calls
By: Leif Madsen (lmadsen) 2009-01-12 10:28:17.000-0600

Assigned to otherwiseguy for review.
By: Terry Wilson (twilson) 2009-01-12 10:37:49.000-0600

Why not just Set(CALLERID(name)=My Corporation in the Dialplan on numbers that are to go out of a trunk?  That is what I've always done.  And it works for all technologies at once.  I don't think this would be accepted unless I'm missing something?
By: Leif Madsen (lmadsen) 2009-01-12 10:40:11.000-0600

Actually that's what I initially thought too, but then got wondering if that only changes it for the RPID?

If your method changes the From: header as well, then this functionality is already available, and would not be necessary to be added to Asterisk.
By: nick_lewis (nick_lewis) 2009-01-12 11:03:34.000-0600

In the current code there is a comment:

/* if we are not sending RPID and user wants his callerid restricted */

and it is followed a couple of lines later by:

if (!ast_strlen_zero(p->fromname))
 n = p->fromname;

but currently there does not seem to be anything setting p->fromname so it is always zero length. My patch primarily creates a peer->fromname and copies it to p->fromname when a dialog is created so that the existing "n = p->fromname" does what I expected

I my have misunderstood though
By: Terry Wilson (twilson) 2009-01-12 11:13:49.000-0600

It looks like fromname is first set from n, which is originally set to p->owner->cid.cid_name, which could be set from the CALLERID(name).

Nick_Lewis, could you try adding a Set(CALLERID(name)=My Coproration to your outbound dialing and see if that works for you?  I can test here, but would have to set up a second Asterisk box.  But the code looks like fromuser will only be set via the channel cid, which will initially be set by the callerid= line in sip.conf, after that, it is up to you to use the CALLERID() dialplan function.
By: nick_lewis (nick_lewis) 2009-01-12 11:55:53.000-0600

I think fromname is set from n if it does not exist

I guess the same could be said of fromuser which is set from l which is originally set to p->owner->cid.cid_num which could be set from the CALLERID(num). However in this case fromuser does exist because it is copied from peer->fromuser.

I accept that dialplan setting CALLERID(name) affects the From: header but this seems inconsistent with CALLERID(num) which does not affect the From: header if fromuser exists.

Currently p->fromname is doing nothing at all and if using the dialplan is the way to go then lets remove the unnecessary code and pvt element.
By: Terry Wilson (twilson) 2009-01-12 12:23:52.000-0600

> I think fromname is set from n if it does not exist
Yes, and it will be used to reset n to whatever p->fromname was the first time that it was modified.  So, basically it sets it to the original cid name, then uses that from then on.

initreqprep is called any time that transmit_invite is sent with init > 1, which happens all over the code.  Removing the p->fromname looks to me like it at least has the potential to cause changes to behavior.  Even under the very best circumstances it would require tons of testing and and an ABI change, for no real benefit.
By: nick_lewis (nick_lewis) 2009-01-13 03:03:54.000-0600

I thought initreqprep was called when the dialog was first created. Even if initreqprep is called during the dialog I think p->owner->cid.cid_name is unchanged so could be used directly each time.

However I agree that there is no benefit in testing to confirm this. I was more interested in adding peer->fromname than removing pvt->fromname. If this is a no-go then I will accept defeat and instead get freepbx changed to support cid name on trunks
By: Terry Wilson (twilson) 2009-01-13 10:17:26.000-0600

That would probably be the best way to go.  We try to repeat to ourselves "Asterisk is multi-protocol PBX" when looking at changes for inclusion.  If there is a way to handle something for all channel types, we tend to prefer that to changes for individual channels.

BTW, if you are the Nick Lewis that contributes to freepbx and drupal (or maybe those are different Nick Lewis'?), "Hi!" and "Thanks!"
By: Terry Wilson (twilson) 2009-01-13 10:18:37.000-0600

Closing since there is a multi-protocol way to handle this through the dialplan.