Leif Madsen wrote:
> Darrick Hartman wrote:
>> I know the call parking feature changed in 1.4.23.1 to fix some serious
>> issues. I'm seeing a major change though which I find disturbing.
>>
>> A person parks a call by transferring it to the parking position (700).
>> When the timeout value is reached, the call is NOT returned to that
>> device, but rather the 's' extension of the phone's registered context
>> (in this case [unrestricted]).
>>
>> -- Executing [...@unrestricted:1] Park("SIP/100-08217d38", "") in
>> new stack
>> == Parked SIP/100-08217d38 on 7...@parkedcalls. Will timeout back to
>> extension [unrestricted] s, 1 in 60 seconds
>> -- Added extension '701' priority 1 to parkedcalls
>> -- <SIP/100-08217d38> Playing 'digits/7' (language 'en')
>> -- <SIP/100-08217d38> Playing 'digits/0' (language 'en')
>> -- <SIP/100-08217d38> Playing 'digits/1' (language 'en')
>> -- Started music on hold, class 'default', on SIP/100-08217d38
>>
>>
>> Is there any way to have the call returned to the device that parked the
>> call (without creating a separate context for each device).
>>
>> For now I created an extension in the [unrestricted] context which sends
>> the call back to the IVR menu, but that's just annoying to the person
>> who placed the call. It should come back to the original device that
>> parked the call. Always did before.
>
>
> There will be a couple of new release candidates going out tomorrow morning.
> Can
> you test them once they are announced to determine if this is still an issue?
> If
> so, then I would suggest you verify the bug does not exist on the bug tracker
> already, and if it doesn't, then you can open a new issue.
This was probably a miss-use of the system by me as explained by someone
else off-list, but perhaps it's still a bug. It ONLY happens with blind
transfers. If you use an attended transfer, the behavior works as
expected. This is a change from past behavior, but it makes more sense
to use an attended transfer to the parking location OR the one step park
feature instead.
Darrick
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
