[asterisk-bugs] [JIRA] (ASTERISK-15685) Repark a call on Parkinglot

Carol Dupont (JIRA) noreply at issues.asterisk.org
Tue Jan 21 09:57:03 CST 2014


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

Carol Dupont commented on ASTERISK-15685:
-----------------------------------------

Hi, 
We just experienced this problem with Asterisk 11.4. Is there anything we can do to help fix this? 
Thanks
                
> Repark a call on Parkinglot
> ---------------------------
>
>                 Key: ASTERISK-15685
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-15685
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/General
>            Reporter: Miguel Ángel
>         Attachments: log
>
>
> Hello,
> We have a problem with multiparking and parkinglots, I'll try to explain because my English is not very good.
> We work in a multi-company environment and we want every one of these companies has its own parkinglot.
> The main problem is that we can't re-park the calls.
> I will try to explain with an example.
> Take for example the extensions 2111 and 2222 belonging to one company.
> In sip.conf for this company we put in his mask
> parkinglot = parkinglot_chemtrol
> and in the context to which we belong to all extensions
> include => parking_chemtrol
> So far so good, but doing some tests
> - 2111 calls extension 2222
> - extension 2222 answers
> - extension 2222 parks the call with ASTERISK-52
> - The call is parked at position 201
> - 2222 extension marks 201
> - extension 2222 retrieves the call and connect with 2111 extension
> this is the performance we want and does, what is wrong is from now
> If extension 2222 tries to REpark the call again, only hear DTMF sounds of either pressing # 56
> Also, if the call is recovered, if 2111 extension try to park pressing ASTERISK-52,it parks, but at position 561 of "parkinglot" general, which can not be recovered.
> In conclusion no longer possible to re-park a call. And if is the caller who tries to re-park, park the call in parkinglot for general context, not in their parkinglot.
> Another thing is when a parked call ringback to extension that parkred previously , now you can park again, I will explain:
> The extension 2111 calls to 2222
> The extension 2222 answers
> Extension 2222 parks the call with ASTERISK-52
> The call is parked at position 201
> Pass the timeout and the call of 2111 returns to 2222
> The extension 2222 answers
> 2222 re-parks the call with # 56
> Now you can pick the call parked at position 201
> Do not know if it's a configuration error or a BUG of Asterisk, we have tested thousand configuration changes and the result is always the same.
> I do not know if I explained correctly.
> It's an issue where we need your help.
> If you need a better explanation, tell me. We're pretty desperate with this issue.
> Thank you very much and best regards.
> Sorry my English
> I put the pieces of the configuration files.
> ****** ADDITIONAL INFORMATION ******
>     ############ FEATURES.CONF #################
>     [general]
>     parkext => 56
>     parkpos => 561-661
>     context => parkedcalls
>     parkinghints = no
>     parkingtime => 300
>     ;comebacktoorigin = yes
>     courtesytone = beep
>     parkedplay = caller
>     parkedcalltransfers = caller
>     parkedcallreparking = caller
>     parkedcallhangup = caller
>     parkedcallrecording = caller
>     ;adsipark = yes
>     ;findslot => next
>     ;parkedmusicclass=default
>     transferdigittimeout => 30
>     ;xfersound = beep
>     ;xferfailsound = beeperr
>     pickupexten = *8
>     featuredigittimeout = 2000
>     ;; Parkinglots de todas las empresas ajenas a Isotrol ;;
>     [parkinglot_cta]
>     context => parking_cta
>     parkpos => 301-330
>     parkedcalltransfers = caller
>     parkedcallreparking = caller
>     findslot => next
>     [parkinglot_consorcio]
>     context => parking_consorcio
>     parkpos => 201-230
>     findslot => next
>     ############### EXTENSIONS.CONF ###################
>     [outgoing_cta]
>     include=>extensiones_cta
>     include=>extensiones_bluenet
>     include=>moviles
>     include=>fijos-nacionales
>     include=>internacional
>     include=>servicios
>     include => parking_cta
>     include => emergencias
>     include => especiales_cta
>     [outgoing_grupo_chemtrol]
>     include=>extensiones_grupo_chemtrol
>     include=>extensiones_bluenet
>     include=>fijos-nacionales
>     include=>internacional
>     include=>moviles
>     include=>servicios
>     include => parking_chemtrol
>     include=>emergencias
>     include=>especiales_grupo_chemtrol
>     ################## SIP.CONF #####################
>     ;--------Mascara de cta
>     [cta_mask](!)
>     secret=ct4
>     callgroup=22
>     pickupgroup=22
>     type=friend
>     host=dynamic
>     context=outgoing_cta
>     parkinglot=parkinglot_cta
>     canreinvite=no
>     disallow=all
>     allow=alaw
>     dtmfmode=rfc2833
>     qualify=3000
>     nat=yes
>     call-limit=9
>     ;--------Mascara de Grupo_Chemtrol
>     [grupo_chemtrol_mask](!)
>     secret=nus1m
>     ;callgroup=20
>     ;pickupgroup=20
>     type=friend
>     host=dynamic
>     context=outgoing_grupo_chemtrol
>     parkinglot=parkinglot_chemtrol
>     canreinvite=no
>     disallow=all
>     allow=alaw
>     dtmfmode=rfc2833
>     qualify=3000
>     nat=yes
>     call-limit=5

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list