[Home]

Summary:ASTERISK-26108: parking: Cannot create parking lots with extension over 2147483647
Reporter:David Sovereen (dsovereen)Labels:patch
Date Opened:2016-06-10 15:50:44Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:Features/Parking
Versions:11.20.0 GIT Frequency of
Occurrence
Related
Issues:
Environment:FreePBX Distro 6.12.65-31Attachments:( 0) ASTERISK-26108_parking-ast13.22.patch
( 1) ASTERISK-26108_parking-ast16.0.0.patch
Description:Cannot make parking lots with an extension that exceeds 2147483647.  "features reload" succeeds, but "features show" shows extensions counting back as you go over 2147483627 and extensions more than double 2147483627 don't show up at all.

In my features.conf, I have (among other things):

[parkinglot_44]
parkext=2147483649
parkpos=2147483650-2147483650
context=parkinglot_44
parkext_exclusive=yes
parkingtime=45
comebacktoorigin=no
parkedplay=both
parkedcalltransfers=caller
parkedcallreparking=caller
parkedmusicclass=default
findslot=first

[parkinglot_45]
parkext=9898373790700
parkpos=9898373790701-9898373790702
context=parkinglot_45
parkext_exclusive=yes
parkingtime=45
comebacktoorigin=no
parkedplay=both
parkedcalltransfers=caller
parkedcallreparking=caller
parkedmusicclass=default
findslot=first

Note that the first one, parkinglot_44, is just over the magic 2147483647 number.  After a "features reload", the parking lot shows as a different extension, 2147483640:

Call parking (Parking lot: parkinglot_44)
------------
Parking extension     :      2147483640
Parking context       :      parkinglot_44
Parked call extensions:      2147483641-2147483641
Parkingtime           :      45000 ms
Comeback to origin    :      no
Comeback context      :      parkedcallstimeout
Comeback dial time    :      30
MusicOnHold class     :      default
Enabled               :      Yes

The second parking lot configured at extension 9898373790700 does not appear in "features show" at all.

We have telephone extensions and other things on our Asterisk systems using numbers larger than 2147483647, but Parking Lots seem to have this limitation.  It would seem that they are stored in the database or in memory as an integer instead of a large integer or string.  I'm hoping this can be fixed, as our internal, normalized naming convention creates parking lots with extension numbers larger than 2147483647.

Thanks,

Dave
Comments:By: Asterisk Team (asteriskteam) 2016-06-10 15:50:45.375-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Richard Mudgett (rmudgett) 2016-06-10 18:57:02.257-0500

Yes, the parking feature uses a 32 bit integer for the parking spaces.  This is something that cannot handle normalized telephone numbers.  You need to come up with a different strategy for your parking lots as parking is implemented as intended and to make it work as you are trying is a feature request which requires a patch.

You could work around your number normalization by doing something like:
{noformat}
[my_context]
; Parking space extens (You could of course use exten patterns)
; Assuming parkpos=701-702
exten = 9898373790701,1,Goto(701,1)
exten = 9898373790702,1,Goto(702,1)

; For Asterisk v11 and earlier, if the parking space is not
; holding a call then the parked call exten does not exist
; and the invalid 'i' exten gets executed.
exten = i,1,Noop()
same = n,Playback("pbx-invalid")
same = n,Hangup()

include=parkinglot_45
{noformat}

Using normalized telephone numbers as parking spaces also subjects your users to listening to lengthy parking space numbers.

See \[3] for more information on ways you can implement call parking.


Features requests without patches are not accepted through the issue tracker. Features requests are openly discussed on the mailing lists, forums, and IRC \[1]. Please see the Asterisk Issue Guidelines \[2] for more information on feature request and patch submission.

\[1] http://asterisk.org/community/discuss
\[2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines
\[3] https://www.asterisk-blog.com/2016/03/30/setup-call-parking

By: Joshua C. Colp (jcolp) 2016-06-13 10:56:23.915-0500

This is a limitation with the implementation itself that is unlikely to be changed per Richard's comment. If you'd like to try then we'd welcome a patch to do so. He's also provided a work around.
By: khb (khb) 2018-08-16 10:38:59

I would like this issue to be reopened for submission of patches to permit much longer parking extensions, per the original request by reporter David S.
By: Richard Mudgett (rmudgett) 2018-08-16 10:51:56.215-0500

Reopened and waiting for a patch put up on gerrit \[1].  The commit message needs to reference the issue in the commit message \[2].  Please be aware of which branches \[3] the patch can go on.

\[1] https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process
\[2] https://wiki.asterisk.org/wiki/display/AST/Commit+Messages
\[3] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
By: khb (khb) 2018-08-16 11:11:18.430-0500

Here are patches for Asterisk 13.22.0 and for Asterisk 16.0.0-rc1. The 16-patch also cleanly applies and compiles with this week's clone from Gerrit.

The 13-patch was tested on a source-compiled 32-bit system, and by patching, rebuilding, and installing RPM distro files for a FreePBX distribution upgraded to Asterisk 13.22.0 on a x86_64 VM system.

The two patches are different, accounting for later additions to the parking code.

The strategy of the patches is to extend all integers (int and unsigned int) that represent parking extensions to use long long integers by using a typedef ast_parkingspace_int to visibly identify those variables that need the extension, which is not in all places obvious without understanding of the details of the code.

By: Benjamin Keith Ford (bford) 2018-08-17 09:56:47.787-0500

[~khb], this change can only go in master. Are you going to be submitting this patch to Gerrit?
By: khb (khb) 2018-08-17 14:02:14.942-0500

I managed to submit patches to 13, 15, 16, and master, and got emails from Jenkins2.
I didn't see the change in your post until now.


By: Benjamin Keith Ford (bford) 2018-08-17 14:06:41.028-0500

That's fine! You can abandon the changes in 13, 15, and 16 and focus on the master patch. The reasoning for this is because it is considered a new feature, and therefore can only go in master.
By: khb (khb) 2018-08-17 14:09:05.723-0500

I would consider it a long-standing BUG. Asterisk extensions can be much longer, the limitation using 32-bit integers cannot be considered a proper implementation.  The same might be said of 64-bit integers, but telephone numbers do have a limit of 15 digits.
By: Richard Mudgett (rmudgett) 2018-08-17 14:18:04.172-0500

Earlier comments have already explained why it is not considered a bug.  It is how parking is being used that is unusual.
By: David Sovereen (dsovereen) 2018-08-20 11:26:54.884-0500

I am the original reporter of this bug/problem/limitation.  I am not a programmer and do not fully understand the code contribution process.  My understanding is that you are saying that because you have called this a "New Feature," this fix/improvement can only go into Asterisk 16 and cannot be put into 13.  That puts khb and me into a quandary.  I hired khb to fix this, with payment to be made after the fix appeared in Asterisk 13 and 16.  If you are saying the fix can only go into 16, then I am left to either pay khb for a fix that isn't in Asterisk 13, where I need it, or leave khb unpaid due to circumstances beyond his control.

Both of us viewed this as a bug and it never occurred to us that this fix wouldn't be allowed into Asterisk 13.  I am asking that this please be relabeled a "Bug" or "Improvement" or whatever is necessary to allow the fix to be put into Asterisk 13 so that khb can deliver the fix in Asterisk 13 and I can pay him for it as intended.  Thank you for your reconsideration.

Dave
By: Richard Mudgett (rmudgett) 2018-08-20 12:28:34.112-0500

[~dsovereen] The patch cannot go into any released branches as the changes necessary break API/ABI \[1].  The patch *can* go into the master branch from which Asterisk 17 will eventually be derived.  It is too late to get into Asterisk 16 \[2] as the last call for features went out a couple months ago \[3] \[4] and the 16 branch has since been created.  As stated when you originally opened the issue two years ago this is a limitation of the parking module and not a bug.  Parking is working as originally designed.  It is your use of parking that is unusual.

Since Asterisk is open source there is nothing preventing you from backporting a patch to the 13 branch and running that code on your servers.

\[1] https://wiki.asterisk.org/wiki/display/AST/New+Feature+Guidelines
\[2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
\[3] https://blogs.asterisk.org/2018/04/18/asterisk-16/
\[4] http://lists.digium.com/pipermail/asterisk-dev/2018-July/076927.html
By: David Sovereen (dsovereen) 2020-02-04 13:11:10.654-0600

Would anyone following this issue be able to help me get this added to Asterisk 17?  The person I paid the bounty to is not responding anymore, so it will not get in there without someone else's help.  We are not programmers/software developers, only an end-user.  We run PBXact, a commercial product from Sangoma, so backporting to Asterisk 13 is not an option.