[Home]

Summary:ASTERISK-06180: [patch] One Touch Parking as built-in feature
Reporter:Noah Miller (noahisaac)Labels:
Date Opened:2006-01-24 14:29:43.000-0600Date Closed:2006-05-22 13:05:35
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) OneTouchPark_2.diff
( 1) OTP-features_conf.diff
Description:This patch adds parking as a feature to res_features.c.  The goal was to allow one-touch parking.

The standard newbie-coder warning applies:  My coding skills are bad, so please tell me what needs to be changed.

That being said, I've really only added one line of my own.  The rest is a copy of the builtin_blindtransfer() function, with a few non-applicable things taken out.  This makes this entire patch extremely redundant, so if there is a better way to go about this, please let me know.  If this is a reasonable way to do this, I'm sure that this code can be trimmed down much more.

We're going to put this into production on our 1.2.2 (tarball) servers, so that's the version of res_features.c that I worked with.

Also, about the patch file: 1) I've never made one before, so let me know if it needs work, 2) I haven't yet sent in the disclaimer, but I will if anyone thinks this is useful.

I can't figure out how to add more than one diff file to this post, so I'll just add here that in features.conf, to activate this feature, you can use "autopark => *" in the [featuremap] section.  To activate in the dialplan, use the standard "tT" flags for Dial().
Comments:By: Olle Johansson (oej) 2006-01-24 14:37:26.000-0600

Thank you for contributing!

Please read the bug guidelines. If you don't send a disclaimer, we can't touch your code. Send a disclaimer according to the bug guidelines (on the home page, and a link when you opened this bug) and confirm it here, so we can move forward looking into this function.

Thanks.
/Olle
By: Olle Johansson (oej) 2006-01-24 14:38:20.000-0600

Also, all patches for new functions has to be to svn trunk, not the 1.2 branch.
By: Noah Miller (noahisaac) 2006-01-24 15:22:00.000-0600

Thanks Olle!

Sorry for not reading carefully enough about the disclaimer.  I've faxed it on over.

I also added a patchfile version for the SVN trunk (res_features.c revision 8410, Sat Jan 21 22:09:06 2006 UTC).

Thanks!
By: Kevin P. Fleming (kpfleming) 2006-02-14 16:11:43.000-0600

I don't understand what is going on here... why do you need to collect a parking extension number from the person who invoked the feature? Isn't the feature code itself enough to park the other channel?
By: mike240se (mike240se) 2006-02-14 23:55:16.000-0600

So the concept would be to allow parking by just hitting * for example?  Instead of transfer and then 700 for example?  I would like to see a parking space that can be linked to snom phones so that 1 button is a) a parking spot, b) an auto park button, c) light up when a call is parked, d) and pick up when the button is pushed and a call is parked.  THere is another patch for allowing BLF but you still cant park and unpark with 1 button on all phones in a small office setup.  Small offices want to be able to easily share calls between them, aka put a call on hold on one phone and pick it up on another.
By: Noah Miller (noahisaac) 2006-02-15 08:26:29.000-0600

To Kevin Fleming:

> why do you need to collect a parking extension number
> from the person who invoked the feature? Isn't the feature
> code itself enough to park the other channel?

Sorry for my ignorance and hackish coding.  I did try removing the ast_app_dtget() call, but I ran into some problems when I did that.  I'll see if I can straighten those out now.  By the way, do I need to have "AST_FEATURE_FLAG_NEEDSDTMF" in the feature definition, or can I get rid of that?


To Mike240se:
> So the concept would be to allow parking by just hitting * for example?

Bingo.  In fact, that's just the key I'm using.


> I would like to see a parking space that can be linked to snom phones
> so that 1 button is a) a parking spot, b) an auto park button, c) light up
> when a call is parked, d) and pick up when the button is pushed and a
> call is parked.

We use mostly Polycom phones, and I did a) and d) by assigning extra line keys as speed dials to the first couple of parking spaces (we never really use more than two parking spaces anyway).  I know you can do the same with Snom phones.  As far as c), you might be able to do that by using hint().  I don't know, I haven't tried, but it would save the time of waiting for Alison to speak out the digits.  I don't really know anything about BLF, but maybe I can start reading ;-)  For b), I just settled on having the park key and the pickup key as different buttons, and that's fine for my users.

A general note to Polycom users: there's a bug in firmware versions 1.5.x - 1.6.4 that prevents speed dials from being mapped to hard keys (I've notiied Polycom, but maybe other people should notify them, too!).  I wanted to do this to have one-button park pickup on IP50Xs.  It works on 1.4.1 and earlier, but those firmware version have some other drawbacks.

Thanks,
Noah
By: Noah Miller (noahisaac) 2006-02-15 08:45:25.000-0600

To Kevin Fleming:

> why do you need to collect a parking extension number
> from the person who invoked the feature?

I actually looked over my patch again (duh), and I realized that I did remove the ast_app_dtget() call, so I'm not sure exactly which part you're referring to.  Do you mean:

strcpy(newext, ast_parking_ext());

If so, I wasn't sure how else to get the extension to transfer to.  If there's a better way, and you could point me toward it, I'd appreciate it.

- Noah
By: Noah Miller (noahisaac) 2006-02-15 11:26:34.000-0600

Hi Again -

Kevin, sorry for being dense.  Call me stupid and poke me like a piñata.  I have no idea what that means, but I guess what I'm really doing is calling ast_park_call() with the context sensing of builtin_blindtransfer().  So, I see what you mean - why would I have to get the park extension?  It's already defined, and so is the parking function.  I thought doing some error checking, but that's not necessary either, since it's already taken care of in ast_park_call().  So, I removed the line that I had added and a whole lot more transfer stuff for unknown extensions that is unnecessary.  I posted some more patches.  The SVN one is against res_features.c from Tue Feb 14 19:14:15 2006 UTC.  Does this look more reasonable?

- Noah
By: Olle Johansson (oej) 2006-04-03 15:48:38

Guess we are waiting for response from kpfleming here...
By: BJ Weschke (bweschke) 2006-05-08 09:52:09

Closing as I'm pretty sure this feature is now already implemented via [applicationmap] and DYNAMIC_FEATURES in Asterisk. If not, my apologies in advance and pls reopen.
By: Noah Miller (noahisaac) 2006-05-08 10:05:44

Hi bweschke -

> Closing as I'm pretty sure this feature is now already implemented via
> [applicationmap] and DYNAMIC_FEATURES in Asterisk. If not, my apologies in
> advance and pls reopen.

Unfortunately, this is not taken care of by applicationmap.  I tried that route, but it never gets the contexts correct.  The parking space number is always played to the caller instead of the callee.  That's the main reason I went about trying this method.

Thanks,
Noah
By: BJ Weschke (bweschke) 2006-05-08 10:08:55

noahisaac: that sounds like a bug with applicationmap. Would your issue be resolved if it did play back the parking spot to the caller?

Just for my own sanity: You want to be able to park a caller by pressing a mappable DTMF string and the person doing the parking (pressing the digits) should hear what extension they've parked the call at, yes?

Thanks. :)
By: Noah Miller (noahisaac) 2006-05-08 10:13:26

> noahisaac: that sounds like a bug with applicationmap. Would your issue be
> resolved if it did play back the parking spot to the caller?

Yes, absolutely.  I admit that I didn't understand the applicationmap code.  I could only get a handle on the transfer code, so I used that.


> Just for my own sanity: You want to be able to park a caller by pressing a
> mappable DTMF string and the person doing the parking (pressing the digits)
> should hear what extension they've parked the call at, yes?

That's just it.  That'd be perfect.

Thanks for checking back with this!

- Noah
By: BJ Weschke (bweschke) 2006-05-22 12:21:42

Closing. This feature has now been committed to /trunk. Thanks!
By: BJ Weschke (bweschke) 2006-05-22 12:22:45

Committed to /trunk. Thanks!
By: Serge Vecher (serge-v) 2006-05-22 13:05:35

for the record, this was patch builtin-parkcalls.diff from bug ASTERISK-6904. Revision 29467 of trunk