[asterisk-bugs] [JIRA] (ASTERISK-26108) Cannot create parking lots with extension over 2147483647

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=230989#comment-230989 ] 

Richard Mudgett commented on ASTERISK-26108:
--------------------------------------------

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


> Cannot create parking lots with extension over 2147483647
> ---------------------------------------------------------
>
>                 Key: ASTERISK-26108
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26108
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Features/Parking
>    Affects Versions: 11.20.0
>         Environment: FreePBX Distro 6.12.65-31
>            Reporter: David Sovereen
>            Severity: Minor
>
> 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 



--
This message was sent by Atlassian JIRA
(v6.2#6252)