[Migrated from old forumParticipant April 11, 2015 at 3:05 am Post count: 327]

#5914 |

having trouble with what i’m sure is very basic thing… once you know what extension to transfer the caller to, what is the right way on VDP to transfer the call to the extension, then have the caller go to whatever the extension is set to (to voicemail if the caller is not there, or to follow me, etc… whatever is set)

i am currently trying to use the ‘dial’ building block and am setting the extension to SIP/${SPEECH_TEXT(0)} (from the results of a lumenvox building block).

the caller gets transferred correctly to SIP/101 for example. but if 101 doesn’t pickup, the call gets dropped. how can i have the call start executing as if the ext was 101 and follow all of the ‘rules’ for 101?

[Migrated from old forumParticipant April 11, 2015 at 3:05 am Post count: 327]

#5915 |

solved my own problem. don’t know if this is the recommended approach, but if you use a ‘goto’ block and set the context to ‘from-did-direct’ and the extension to a variable like ${SPEECH_TEXT(0)} or just a number like ‘101’. it works for me. The ‘ext-did’ context suggested in the tutorials didn’t work for me for some reason.

i use elastix, perhaps that’s why.

[Migrated from old forumParticipant April 11, 2015 at 3:05 am Post count: 327]

#5916 |

mmm… same question but for queues… when i use the queue block, i can set the queue number to ${SPEECH_TEXT(0)} but i get a warning from VDP that ${SPEECH_TEXT(0)} is not a known resource. seems to work though…

[Migrated from old forumParticipant April 11, 2015 at 3:05 am Post count: 327]

#5917 |

This message is given because at design time Visual Dialplan can not recognize resource Queue ${SPEECH_TEXT(0)} but at run time it will replace ${SPEECH_TEXT(0)} with valid resource (registered queue number).

[Migrated from old forumParticipant April 11, 2015 at 3:06 am Post count: 327]

#5918 |

yes, i realize it works and why the error message appears, but it’s a huge pain to have all of your queues lit up in orange and that message every time you deploy. the goto block doesn’t behave that way, only queue and dial seem to generate the unnecessary(imho) warning.

anyway, here is a workaround i found for what it’s worth to anyone reading this…

1) create a global variable (something like queuename) to store the variable
2) use a SET block to set the global variable.
3) then use the global variable in your queue or dial block instead of the ${SPEECH_TEXT(0)} type variable and then you don’t get the error message. this has the added benefit of having the variable in the dropdown select list for you. (the downside is that you longer code that’s harder to maintain since it takes 2 blocks with 2 variables to do what could(imho) be done in one)

[Migrated from old forumParticipant April 11, 2015 at 3:06 am Post count: 327]

#5919 |

Thanks for a workaround. cool 🙂