That is correct to some extent, but depends on what you are implementing. If there is app requirement that requires the user to come back to the IVR app , you have to do it this way ie from within the VXML app. This is the case where it is a bridged transfer.
Also the vxml specs allow the state to be checked at the other end like if it is busy, no answer, network busy etc and take appropriate action.
So it all depends on what your reqs are. I have done several complex call control/conferencing apps and this allows it.
Hemal
Hemal,
Techinically VXML call control should only be applied in a standalone deployment. Even the 8.5 SRND says this is not supported w/ ICM and CVP. Ch.10 pg. 5 reads: "<font size="2">
Most Unified CVP customers use Unified ICM Managed transfers. Unified CVP performs this function most naturally, providing gateway-based switching for Unified ICM and Unified CCE installations. In Unified CVP deployments with Unified ICM, Unified ICM provides all call control. VoiceXML call control from the Unified CVP VXML Server is not supported when Unified ICM is deployed with Unified CVP. "
</font>
I'm
not trying to discredit your advice tho, only suggesting that if you want Cisco
support, it is usually best to stick to the SRND. I haven't done much call
control in VXML yet so I cannot comment on its effectiveness but it seems to be
a very useful solution in the right respects.
Also,
perhaps Winai is talking about post-route transfers from one agent to another
allowing consultation, I wouldn't be the best person to speak to solutions for
this either as I've only done the warm-transfer model using CTI route points
and a post-route script to route/re-queue the transfer to a skill.
I
have just heard of a run-in with TAC from a member on my team regarding this
scenario, just wanted to give reference to some documentation that TAC would
likely point out themselves.
Ryan