On 9 March 2012 21:55, John <freeswitch@earthspike.net> wrote:
It sounds like something that would be better driven from the ESL rather than a script that effectively forms part of the dialplan. As João says, when you lose the leg you are executing inside, you lose control.
Hmm, I think i found the cause of the problem - Polycom is handling "Attended Transfers" resp. "Consultation Transfers" somewhat unorthodox, where B does not have to wait for C to pickup - FS can't cope well with this situation. A proper Attended Transfer or a proper Blind Transfer handles these situations much better. Anthony pointed this out to me offlist on an other issue. In essence, i have the option to reconfigure my Polycoms to not allow to transfer unanswered Attended Transfers with the parameter "voIpProt.SIP.allowTransferOnProceeding" - and instruct my clients how to use a "real" Blind Transfer instead. With a proper Blind Transfer, A sends a invite to C and the call is reinitated properly from the start. This issue was really bugging me for 2 weeks now, but the solution appears simple and at a totally different place than i had looked. Who would have thought? :-) Sometimes you lose sight of the forest for the trees...
Also, you are far better posting logs to pastebin.freeswitch.org. The URL stays in the original post whereas the attachment gets lost further down the post chain. And they are easier to read.
Ah, yeah, thanks. I was so distracted and cocerned that i forgot about that ;-) Cheers, Christian