[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