Summary:ASTERISK-03415: include calleridname when app_dial changes callerid
Reporter:Matt Florell (mflorell)Labels:
Date Opened:2005-02-01 22:48:46.000-0600Date Closed:2008-01-15 15:24:51.000-0600
Versions:Frequency of
Environment:Attachments:( 0) app_dial_CID_nodelete.patch
( 1) app_dial_patch.txt
( 2) Manager_output_call_from_meetme.txt
( 3) senddialevent.txt
Description:As of Asterisk 1.0.5(or 1.0.4, not sure) all calls that are placed through app_dial(Zap, IAX2, SIP) have the callerID that was set when the call was placed deleted and replaced only with the exten/macroexten.

I have read the bug that created this change http://bugs.digium.com/bug_view_page.php?bug_id=0002489 and am wondering if it would be possible, and not conflict with any of the reasons that this change was made, to include the original callerid or calleridname that was set when the call was initiated as the calleridname of the new callerid.

This would greatly help send custom information along with the call including who it is you are calling as well as allow for unique tagging of call instances which is still not possible any other way in asterisk.

Also, a question, any reason why calleridname as a seperate manager output line was stopped in the last release?
Comments:By: Matt Florell (mflorell) 2005-02-02 11:26:00.000-0600

Uploaded patch for Asterisk v1.0.5 to remove the callerID deletion after dialing(before ringing). It's a very simple patch, just deletes 4 lines of code from apps/app_dial.c

I'm positive this won't be included in a release because it basically eliminates what the developers just changed. But now everything I am using works again. Maybe a config file option or a dial time option for enabling/disabling this would be nice.

By: Mark Spencer (markster) 2005-02-02 13:37:03.000-0600

The source of the original problem was that there was a clear logical error in the handling of the callerid of channels in general, being that the outbound channel had the same callerid as the inbound channel.  Put simply, this is not correct if the outbound segment ever ends up doing anything else (even getting parked for example).  The correct callerid for that device is what is being dialed, presumably, and we have added support for hints to associate names with those numbers.

Given the outbound channel, you can still find the original callerid of the inbound leg of its associated call by looking at the bridged channel event and looking at what channel it is bridged to.

By: Matt Florell (mflorell) 2005-02-02 14:20:31.000-0600

Actually you cannot find the original callerid if the call was placed from a Local/ channel going to an exten that dials out and then connect to another exten(think dialing a number from within a meetme conference). The original channel(i.e. Local/917275551212@default-397c,1) ceases to exist once the call is passed to the new outbound trunk channel(IAX2/Zap/SIP). Also, in these cases there are usually 3 separate uniqueids that are created for this single call(2 of them drop off) as well as at least 3 renames of the channels. A custom callerid staying the same throughtout the entire life of the call was the only way to always be able to identify a specific call instance in these cases.

I have uploaded a manager output dump file of a single call Originated from the Manager interfece dialing out from a meetme room to a Local/ extension that dials out through an IAX trunk.

All I really want is either to have the new callerid include the original callerid as calleridname or just have this feature only be activated or deactivated by a dial flag.

By: Matt Florell (mflorell) 2005-02-02 14:31:23.000-0600

Another solution for me and other developers that do complex call routing with custom tagging and need the manager output to track calls would be to implement a CallLabel field in the manager interface like I have suggested several times before. I even wrote a whitepaper on it for discussion at Astricon last year:


Nothing ever became of it, but if this idea was implemented we could go back to using callerid only for what it was supposed to be used for.

By: Mark Spencer (markster) 2005-02-02 14:34:48.000-0600

Try 'p' flag in latest CVS.  Let me know if that does it.

By: nicolasg (nicolasg) 2005-02-02 14:58:29.000-0600

markster: "Given the outbound channel, you can still find the original callerid of the inbound leg of its associated call by looking at the bridged channel event and looking at what channel it is bridged to."

Hi Mark, yes you can find the original callerid looking at the Link event. But you will find it when the call is bridged, and we need to have it before. At least I believe that the callerid is useful before picking the phone up, so you know who is calling. Then any manager based application can do screen pops, or whatever. Having the callerid after picking up is useless.

Maybe we need a new manager Event that displays the callerid of the caller associated to the uniqueid of the Ringing channel. Just my 2 cents..

By: Matt Florell (mflorell) 2005-02-02 14:59:31.000-0600

Thanks, the 'p' flag on dial seems to work(preserves custom callerID)

Please take a look at the whitepaper I linked to above. It would really help to have something like that for Manager API developers like me.

Thanks again

By: nicolasg (nicolasg) 2005-02-02 19:52:45.000-0600

Submited a patch (for your consideration) that generates the manager event I suggested in my previous comment.

The Goal: we need to have the remote callerid available before the channels are bridged on the manager interface.

I don't know if app_dial is the right place to put it, nor if this is the *correct* way on doing it. I also don't know if it solves the problem with local channels. The patch generates a manager event when the state of a channel is set to RINGING with the Remote CallerID and the Uniqueid of the ringing channel. I did very limited testing and it seems to work.

Thanks for listening.

By: nick (nick) 2005-02-02 19:57:17.000-0600

OK... since the p option seems to work, can we close this one on out?

By: nicolasg (nicolasg) 2005-02-02 20:18:58.000-0600

Hi Nick:

No, we can't. Because the bug was reported on STABLE 1.0.5. Not HEAD.  And the p options is only available on HEAD.

Also I would like to discuss a little more the implications of the change, and maybe find a solution that would please us all. It is incorrect to have the callerid of the remote party if you were parked or transferred (the p option will then make things nice on the manager but wrong on other situations), but its also vital (IMHO) to have the remote party caller id on the manager interface before the channels are bridged.

Why can't we find the 'right' fix to this problem? There were other reports related to callerid and all were closed promptly saying that it is not a bug. Maybe it isn't, but we have to fix the manager please!


By: Matt Florell (mflorell) 2005-02-02 20:48:26.000-0600

I'm happy that the 'p' Dial option works in CVS-HEAD(meaning it should be there for future releases), and I can use the patch I posted here to eliminate the callerid changing in the v1.0.5 release, so for now I'm happy. But there is the underlying problem of call tracking within Asterisk and the manager interface.

The only fully functional solution for interface developers, other than significantly altering the Asterisk source code, is to use the Asterisk callerid variable and the manager output of the callerid. There simply is no other way of tracking complex calls. If we had another way of tagging calls(like a "CallLabel" variable) that would be user-definable (set it in an originate, allow "SET CallLabel XXX", etc...) and that would be output like callerid on every event of a call's life we would not need to use callerid to track calls. This would be a wonderful addition and would free up callerid to be used only for what it is supposed to be used for.

I am also all for having callerid output on every stage of a calls manager output events.

By: Steve Murphy (murf) 2005-02-02 21:07:46.000-0600

Just one complaint, guys!

In bug 752, I've coded a patch to complete the Privacy option for the
Dial command. I used the little 'p' as an option for call screening.

My native, lazy, selfish side says, "Hey, I've got dibs on the 'p' option
for app_dial! They should use another letter!!!", but my gracious, forgiving,
understanding, team-player side, says, oh, well, I guess I could use another

You guys judge. P() is for a databased call screening. And the little p is for a non-databased version of the same (at least, so have I proposed!).

The "C" option is to reset call detail. But the "c" option is still open?

Whatever you decide, I'll work around it. It's your call!

By: Matt Florell (mflorell) 2005-02-02 21:14:08.000-0600

In Mark we trust :)

Whatever he codes is final, usually. I was kind of confused why he chose 'p' for this option(Preserve callerID I suppose). It doesn't really matter to me what the flag is, as long as the functionality is in there somehow with some kind of flag, but it's already in CVS-HEAD as 'p'.

By: Mark Spencer (markster) 2005-02-02 21:29:47.000-0600

Changed option 'p' to 'o' for better compatibility with your privacy patch ;)

By: Paul Dugas (pdugas) 2005-02-02 21:56:56.000-0600

I think markster's check-in missed a terminating quote.  Busted build!

By: Mark Spencer (markster) 2005-02-02 22:20:04.000-0600

Sorry, fixed.

By: Steve Murphy (murf) 2005-02-02 23:30:11.000-0600

Thanks for the consideration. Sorry to bother you all. Group efforts
are fun, aren't they? But it is neat watching things come together.

By: nicolasg (nicolasg) 2005-02-07 17:30:19.000-0600

A related bug (3494) was closed today with maybe a solution to this one. I would like to have an event in the manager that relates the two channels and callerid from a dial command in STABLE. The solution given by kram to the above bug can be used here too.

The thing is, it appears to be a new feature, instead of a bugfix, so it wont fit into stable?

But without this event, callerid will be broken for all manager based applications with no workaround.

Also, It appears that the DIAL event is sent only when Local channels are involved, but I would need the event for any type, not just Local or created via the Originate command.

Finally, this event won't solve the problem that mflorell is having, the one reported in this bug. I do not know where to discuss this further, so I'm posting this here.

By: Mark Spencer (markster) 2005-02-08 01:15:19.000-0600

I'll mark this as "resolved" so it goes into Russell's stable queue, but if I were you, I would try to contact him on IRC to follow up explicitly (drumkilla)

By: Russell Bryant (russell) 2005-02-09 16:16:28.000-0600

re-opening so nicolasg can add a patch

By: Russell Bryant (russell) 2005-02-09 16:56:00.000-0600

Ok, so, I decided to just revert the original patch from bug ASTERISK-2451 to preserve the original behavior in 1.0 without having to add an option.  The original bug that was intended to fix will just remain one of the "known issues" in 1.0.

Sorry for any inconvenience it caused you guys!

By: Digium Subversion (svnbot) 2008-01-15 15:24:09.000-0600

Repository: asterisk
Revision: 4954

U   trunk/apps/app_dial.c

r4954 | markster | 2008-01-15 15:24:08 -0600 (Tue, 15 Jan 2008) | 2 lines

Add new 'p' flag to Dial for preserve callerid (bug ASTERISK-3415)



By: Digium Subversion (svnbot) 2008-01-15 15:24:09.000-0600

Repository: asterisk
Revision: 4955

U   trunk/apps/app_dial.c

r4955 | markster | 2008-01-15 15:24:09 -0600 (Tue, 15 Jan 2008) | 2 lines

REname 'p' option to 'o' (bug ASTERISK-3415)



By: Digium Subversion (svnbot) 2008-01-15 15:24:51.000-0600

Repository: asterisk
Revision: 4994

U   branches/v1-0/apps/app_dial.c

r4994 | russell | 2008-01-15 15:24:51 -0600 (Tue, 15 Jan 2008) | 2 lines

preserve original callerid functionality for 1.0 (bug ASTERISK-3415)