[Home]

Summary:ASTERISK-04547: [request] Add 'UserField:' parameter to pbx_spool.c
Reporter:Simon Rowland (funky)Labels:
Date Opened:2005-07-10 14:45:14Date Closed:2011-06-07 14:03:03
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:This would function just like the 'Account:' parameter for outgoing calls placed through the callfile spool or through the Asterisk Manager interface.

The userfield would get marked in the CDRs if registered this way.

This is better than adding Setvar: userfield=12345 to the callfile, then adding SetCDRUserField(${userfield}) to the extensions.conf, because SetCDRUserField is not called if the telephone is not picked up by the party receiving the call.

Therefore, there is currently no way to identify who the calls in the CDRs went to if you need to track them using the Userfield for statistics.

****** ADDITIONAL INFORMATION ******

Channel: IAX2/voipprovider/14165551212
MaxRetries: 0
RetryTime: 60
WaitTime: 60
Callerid: 416-405-8073
Extension: s
Priority: 1
Context: dtmftest
Account: dtmftest      ; this is already implemented, and gets stamped on the CDRs
Userfield: 12345        ; this is what needs to be implemented
Comments:By: Michael Jerris (mikej) 2005-07-10 14:49:20

Typically the best way to get a response on a feature request is to put up a bounty on the wiki or contract the work with developers.
By: Clod Patry (junky) 2005-07-13 19:29:22

funky: any interest of making a bounty with this?

And i dont see why you should have that exactly?

just add 1 priority before your called priority and do a SetCDRUserField(foobar), no?


By: Brian West (bkw918) 2005-07-13 22:03:36

This isn't something that is needed.  You can accomplish this about 20 other ways.  NO NEED TO ADD IT!
By: Simon Rowland (funky) 2005-07-14 07:57:37

As described, this is the only way I can see to still have the UserField populated correctly if the call is not picked up.

If you send the call to s,1, SetCDRUserField(uniquetrackingnumber), the CDR will only be stamped with the tracking number if the call is picked up.

If you can think of another way to do this, that doesn't require the call to be picked up for the CDR to have the userfield set correctly, then I'm all ears.
By: Simon Rowland (funky) 2005-07-14 07:59:40

junky: you're assuming that the call is started from a DIAL command within the extensions.conf, rather than from a callfile.
By: Clod Patry (junky) 2005-07-14 10:08:56

no assuming that's via a .call.
I'll provide you an exemple when i got 2 minutes.
By: Brian West (bkw918) 2005-07-14 10:41:33

You use chan_local to make the call via the dialplan and NOT a direct channel name like you're doing.

[outbound]
exten => _1NXXNXXXXXX,1,SetCDRUserField(uniquetrackingnumber)
exten => _1NXXNXXXXXX,2,Dial(IAX2/voipprovider/${EXTEN})
exten => _1NXXNXXXXXX,3,Hangup

Now you dial in your callfile Local/14165551212@outbound instead of  IAX2/voipprovider/14165551212
By: Brian West (bkw918) 2005-07-14 10:42:20

Example provided that will work for your needs.
By: Simon Rowland (funky) 2005-07-14 12:08:46

I'm aware of the option to use chan_local, but I've found it to be unstable at high call volumes (hundreds of simultaneous calls), often producing core dumps. I will open another ticket and upload my backtraces for this issue, which we investigated fairly extensively.

Try using the chan_local code snippet you provided, and launch Asterisk with 50 callfiles waiting in the spool. It will coredump.

Also, Asterisk won't scale as well because there are now two channels in use which have to be bridged.

Because of this, I've stopped using chan_local. Local channels are not stable enough for production in my experience.
By: Brian West (bkw918) 2005-07-14 13:14:49

Well post the backtrace up and we'll fix the problem.. just because it coredumps doesn't mean you shoudln't use it.. lets fix the problem not just do it a different way.

/b
By: sivana (sivana) 2005-07-14 13:20:46

funky, are looking to have it added to the .conf files as a parameter as well?
By: Michael Jerris (mikej) 2005-07-20 23:04:38

closed due to lack of response to the request, and lack of response from original poster.  As what you are requesting is already dooable in asterisk, just not well in the scale you want too, I think a bounty may be the only way you will get this done.  Feel free to re-open this bug when there is code to be reviewed.  I look forward to seeing the crash's related to chan_local
By: Russell Bryant (russell) 2005-07-20 23:54:40

As a sidenote, this bug inspired me and I committed some changes as a result of it.

1) Spool files, as well as manager originate, can now set writable dialplan functions, as well as channel variables.

2) While setting some writable dialplan functions was allowed, it would have gotten reallllllly screwy if you tried to use one that used a pipe symbol to separate arguments.  That has been resolved.

3) Manager originate could actually only set 1 channel variable.  That is no longer a limitation.

4) The CDR() dialplan function has been modified to allow you to set the accountcode and userfield, and not just custom cdr variables.

This is a nice improvement over what was there, but there are still some issues that need to be addressed as far as the timing of when all of these things are set.  However, that is for another day ...