receive back the call when forwarding fails

[trjdj]

Hi,

Anyone who could help me with the following:

A receives a call from X (outside call). X want to speak to user B or group B.
A forwards the call and hang up.

Now, what I would like to have is that when B is busy or does not answer, the call will go back to A and not e.g. voice mail.
This should be so for all users, so if user D receives a call, forward to user P, P is not answering, D will get the call back on his/her extension....

Thanks again!

[vad]

Not forward - transfer.
I don't know why - but in OXE absent feature - when calls return to initiator of transfer.

[haroun]

vad i think that what we called in french "chainage" it's display on the attendant set when receiving incoming call ; in digital set we have to use parc dynamique touch but attdt should be abscent may be in this case

[trjdj]

Hi Vad,

Thanks for taking the time to reply.
I'm sorry if I used the wrong wording. However, how do I configure a transferred call not picked up getting back to the originator of the transfer?

[arad]

Hi everyone.
is there an answer to this post?
i have the same issue and no solution so far .

thank you!

[tgn]

external calls are going to the entity and where transmitted due to the entity distribution table.
internal calls stay where they're transferred.
regards...

[arad]

thank you.
the installation has no attendant. so every user receives external calls via DDI translation.
the customer wants that transferred calls to return to the transfering extension.
in OXO this seems to be the default behaviour. is it posible that they didn't implemented it in OXE?

[tgn]

is it posible that they didn't implemented it in OXE?

yes it is! not implemented. oxe software is designed to work in that way!

regards...

[arad]

not what i expected for a machine in that class, but..
thank you.

PS. is there any kind of workaround to meet such a request ?

[tgn]

not what i expected for a machine in that class

i agree with you... but it is like it is...

PS. is there any kind of workaround to meet such a request ?

i've never tried a workaround.
but maybe this can be a solution.
- make an entity per user (or a group of users, if they are working in a team... maybe) who needs this feature.
- create an ua virtual user
- configure the entity distribution table with the number of the virtual user.
- configure set supervision keys for each team member with number of the ua virtual set.
...
some caveats:
- number of entities are limited
- really huge confguration effort... especially if there are many users...


regards...