Caller gains the ability transfer after being parked

Hi all,

I have a problem I have been unable to solve. I have the following in our main internal context:


exten => 994,1,Dial(SIP/994|60|t)
include => parkedcalls

Nothing special changed in the features.conf.

The problem:

Caller calls 994 and Callee (994) answers - all ok. At this stage, the caller gets nothing when pressing ‘#’. Callee (994) now parks the call (via blind transfer), get the parked extension and hangs up - all still ok.

The problem is that when someone picks up the parked call, both the callee AND the caller are now able to press ‘#’ and initiate a blind transfer.

Is there something I’m likely to have missed in the config or some way to prevent this.

Using version 1.2.6, however the problem was evident in 1.0.9 also.

Cheers,
Graham

You need to post the output of the CLI from the moment the call arrived till parked and the CLI from the moment the call gets picked from the parking pos.

My assumption is, that the call picked from the parkpos. respawns in the local pseudo channel (or vice versa) which’s behaviour is diff.

I’m not sure if this is what you are asking for. In the output below 997 is the caller, calling 994 (the callee).

-- Executing Dial("SIP/997-b87b", "SIP/994|60|t") in new stack
-- Called 994
-- SIP/994-52f1 is ringing
-- SIP/994-52f1 answered SIP/997-b87b
-- Attempting native bridge of SIP/997-b87b and SIP/994-52f1
-- Started music on hold, class 'default', on channel 'SIP/997-b87b'
-- Playing 'pbx-transfer' (language 'en')
-- Stopped music on hold on SIP/997-b87b
-- Started music on hold, class 'default', on channel 'SIP/997-b87b'

== Parked SIP/997-b87b on 981. Will timeout back to extension [private] 994, 1 in 3600 seconds
– Added extension ‘981’ priority 1 to parkedcalls
– Playing ‘digits/9’ (language ‘en’)
– Playing ‘digits/8’ (language ‘en’)
– Playing ‘digits/1’ (language ‘en’)
== Spawn extension (private, 994, 1) exited KEEPALIVE on ‘SIP/997-b87b’

-- Executing ParkedCall("SIP/994-b59f", "981") in new stack
-- Playing 'beep' (language 'en')
-- Stopped music on hold on SIP/997-b87b
-- Channel SIP/994-b59f connected to parked call 981
-- Attempting native bridge of SIP/994-b59f and SIP/997-b87b

[997 presses ‘#’ but enters no extension]

-- Started music on hold, class 'default', on channel 'SIP/994-b59f'
-- Playing 'pbx-transfer' (language 'en')
-- Unable to find extension '' in context 'private'
-- Playing 'pbx-invalid' (language 'en')
-- Stopped music on hold on SIP/994-b59f
-- Attempting native bridge of SIP/994-b59f and SIP/997-b87b

[994 presses ‘#’ but enters no extension]

-- Started music on hold, class 'default', on channel 'SIP/997-b87b'
-- Playing 'pbx-transfer' (language 'en')
-- Unable to find extension '' in context 'private'
-- Playing 'pbx-invalid' (language 'en')
-- Stopped music on hold on SIP/997-b87b
-- Attempting native bridge of SIP/994-b59f and SIP/997-b87b

== Spawn extension (private, 981, 1) exited non-zero on ‘SIP/994-b59f’

Hope this helps.

Ok, from what i see, it is the way that the pound (#) isnt working after the parked call was reconnected !

[997 presses ‘#’ but enters no extension

Means, asterisk is awaiting the extension where to transfer the call to, like seen here:

Unable to find extension ‘’ in context ‘private’

Question, in what context did the call arrived initially?
Can you post extension.conf and features.conf as well please ?

Oh sorry, misreaded…these are comments of you…ok, rereading…second…

Edit:
Ok, back.

Yep, same thing - User 997 is hitting pound but no transfer cuz of missing extension.

We need to take a look at ext…conf and feat…conf

Config Files (edited to shorten in places - nothing critical removed)

— features.conf

[general]

parkext => 98
parkpos => 981-989
context => parkedcalls
parkingtime => 3600
;transferdigittimeout => 3
courtesytone = beep
;xfersound = beep
;xferfailsound = beeperr
;adsipark = yes
;findslot => next
;pickupexten = *8
;featuredigittimeout = 500

[featuremap]
;blindxfer => #
;disconnect => *0
;automon => *1
;atxfer => *2

— extensions.conf

[general]

static=yes
writeprotect=yes
autofallthrough=yes
priorityjumping=no

[globals]

[default]

exten => 990,1,Goto(mainqueue|s|1)

[private]

include => default

;— office1 ----------------------------------------------------------

exten => 991,hint,SIP/991,Office 1
exten => 991,1,Dial(SIP/${EXTEN}|60)

;— office2 ----------------------------------------------------------

exten => 992,hint,SIP/992,Office 2
exten => 992,1,Dial(SIP/${EXTEN}|60)

;— graham -----------------------------------------------------------

exten => 994,hint,SIP/994,Graham
exten => 994,1,Dial(SIP/${EXTEN}|60|t)

;— etc etc ----------------------------------------------------------
;
;exten => 99x,hint,SIP/99x,User x
;exten => 99x,1,Dial(SIP/${EXTEN}|60)

;
; A heap of outbound call routing entries removed
;

include => parkedcalls

[quote=“RichardHH”]
Yep, same thing - User 997 is hitting pound but no transfer cuz of missing extension.[/quote]

To be clear, if either the caller or callee does enter an extension, the call IS transferred.

The transfer is working - I simply hit ‘#’ on both sides to show that it was possible.

Ok, now i got you.

You are saying, that they WERE typing “#” in the first block of your example as well without any result ?

Can you repost you previous long posting and insert exactly, where the “#” sign was pressed in the first block ?

Ok, now im really confused. See your first posting:

[quote]
Caller calls 994 and Callee (994) answers - all ok. At this stage, the caller gets nothing when pressing ‘#’. Callee (994) now parks the call (via blind transfer), get the parked extension and hangs up - all still ok.

The problem is that when someone picks up the parked call, both the callee AND the caller are now able to press ‘#’ and initiate a blind transfer.[/quote]

Ok, then HOW was 994 able to “park the call via blind transfer” when blind transfer isnt working ?

Your features.conf:

The blindtransfer feature is commented out, why ?

Me again, lol.

Ok…i THINK i understand now (sorry, i am german):
You say that !!BOTH!! are able to blindtransfer, after coming back FROM parking.

Well, that is easy:
See your extension.conf.

When you get the parked call back, you spawn the call INTO the extension context the internal phone is spawning in (cuz THAT phone gets him back into the context similar to the internal phone)

And from THERE, everyone can access all other extensions the same…

Is that what you mean ?
The first call (b4 parked) is spawning in a different context (no transfer for both here). But the “got back from parking” call is spawning in another extension, where different rules/extensions are present for both then.

Example:
Think of an incoming context.
Nothing special defined there.
A “WaitExten” command.
Whatever the caller is pressing now, wouldnt do anything because the “incoming” context has no rules (extension) for anymore digits pressed by the caller.

Now imagine an internal phone.
Spawning in your “hot” context, parking the caller.

Whenever the internal phone gets the parked call back, the call respawns in the context of the internal phone.
When you press digits NOW in THAT context, it leads to actions cuz DEFINED in that context.

In short:
THe parked call gets a new contex the moment you fish him back.

See what i mean ?

[ 997 dials 994 ]

– Executing Dial(“SIP/997-b87b”, “SIP/994|60|t”) in new stack
– Called 994
– SIP/994-52f1 is ringing
– SIP/994-52f1 answered SIP/997-b87b

[ 994 answers ]

– Attempting native bridge of SIP/997-b87b and SIP/994-52f1

[ 997 presses ‘#’ but nothing happens or is logged - DTMF ‘#’ is passed to 994 ]

[ 994 presses ‘#’ followed by 98 ]

– Started music on hold, class ‘default’, on channel ‘SIP/997-b87b’
– Playing ‘pbx-transfer’ (language ‘en’)
– Stopped music on hold on SIP/997-b87b
– Started music on hold, class ‘default’, on channel ‘SIP/997-b87b’
== Parked SIP/997-b87b on 981. Will timeout back to extension [private] 994, 1 in 3600 seconds
– Added extension ‘981’ priority 1 to parkedcalls
– Playing ‘digits/9’ (language ‘en’)
– Playing ‘digits/8’ (language ‘en’)
– Playing ‘digits/1’ (language ‘en’)
== Spawn extension (private, 994, 1) exited KEEPALIVE on ‘SIP/997-b87b’

[ 994 has heard the parkpos (981) and hangs up ]
[ 994 now picks up and dial 981 to get parked call ]

– Executing ParkedCall(“SIP/994-b59f”, “981”) in new stack
– Playing ‘beep’ (language ‘en’)
– Stopped music on hold on SIP/997-b87b
– Channel SIP/994-b59f connected to parked call 981
– Attempting native bridge of SIP/994-b59f and SIP/997-b87b

[ 997 presses ‘#’ but enters no extension thus allowing call to come back after invalid extension message ]

– Started music on hold, class ‘default’, on channel ‘SIP/994-b59f’
– Playing ‘pbx-transfer’ (language ‘en’)
– Unable to find extension ‘’ in context ‘private’
– Playing ‘pbx-invalid’ (language ‘en’)
– Stopped music on hold on SIP/994-b59f
– Attempting native bridge of SIP/994-b59f and SIP/997-b87b

[ 994 presses ‘#’ but enters no extension thus allowing call to come back after invalid extension message ]

– Started music on hold, class ‘default’, on channel ‘SIP/997-b87b’
– Playing ‘pbx-transfer’ (language ‘en’)
– Unable to find extension ‘’ in context ‘private’
– Playing ‘pbx-invalid’ (language ‘en’)
– Stopped music on hold on SIP/997-b87b
– Attempting native bridge of SIP/994-b59f and SIP/997-b87b

[ Both ends hang up ]

== Spawn extension (private, 981, 1) exited non-zero on ‘SIP/994-b59f’

Testing something - my mistake. It was not commented during the call logs shown.

[quote]In short:
THe parked call gets a new contex the moment you fish him back.

See what i mean ?[/quote]

I think so but I’m not sure that is the case. This occurs when calling between two extension both in the same context. One might leave while parked but returns to the same context it started in.

If I understand you correctly, what you were describing would mean both should be able to transfer to start with.

Correct (last sentence)

Ok…so they do spawn in the very same context the first time and after reconnecting (you re-checked that right?)

Iam not quite sure now…but what i do see is this:

First call:
– SIP/994-52f1 is ringing

After being parked:
Executing ParkedCall(“SIP/994-b59f”, “981”) in new stack

See the 4 digits after SIP/994 ? The call has been reindexed by asterisk…so technically it is a NEW call for asterisk.

Something is changing at this point, giving the caller the ability to use features/mappings - which he hadnt at first.

I wonder, if Asterisk has an internal mechanism, to exactly AVOID “targets” using features when being called. Only the caller (you, normally internal phone) is able on this leg to initate mappings/features.

But he gets back from a parked position, asterisk obv. handles HIM now “somehow” as the caller, spawning on an internal leg.
And suddenly he gets the accessrights.

I am not sure if i miss something here, but i would really report that in their bugtracker and ask if this is a bug, that the respawning call is somehow handled “trusted from inside” - therefore getting internal rights to the features.

Sorry not being able to help more at this point, but i dont use any features of asterisk, we use SNOM phones and hardbuttons for features.