DTMF interruption question.

[jcanter]

I have a voicemail application that is currently skipping the recording portion of the vxml document if someone presses a DTMF digit. For example, if the greeting is being played and someone presses a digit, it stops playing the greeting, skips the <record> tag( I assume because I am allowing touch tone termination of the record element tag ), and continues to the next prompt.

The behavior I would like to see here is to allow the caller to skip the greeting if they press a digit. I would also like to allow tone tone termination after the caller leaves a recording. I have tired to use the <property> tag to set bargein to false in the <record> tag, however this is setting this behavior accross the entire vxml document. I had thought that the <property> tag was supposeed to follow the same rules as variable scoping.

Here is the code I am using:

Code: Select all

  <!--
  #########################################################################
  #
  #  PlayGreeting: 
  #
  #########################################################################
  -->
  <form id="PlayGreeting">
    <block>
      <audio expr="app_audio_path + 'storage_link/' + app_basePath + 'data/greeting.' + app_greetingType + '.wav'" >
        The user you are attempting to contact is not available at this time, please leave your name and number after the tone.
      </audio>
      <if cond="app_msgOnly == 1">
        <disconnect/>
      <else/>
        <goto next="#RecordMessage"/>
      </if>
    </block>
  </form>

  <!--
  ## #####################################################################
  ## 
  ## RecordMessage: Record the callers information.
  ##
  ## ######################################################################
  -->
  <form id="RecordMessage">
      <property name="bargein" value="false"/>
    <catch event="connection.disconnect.hangup">
      <assign name="doc_timer" expr="callerrecording$.duration"/>
      <assign name="app_callerRecording" expr="callerrecording"/>
      <log>
        Disconnect during record phase.
      </log>
      <goto next="#InsertMessage"/>
    </catch>

    <record name="callerrecording" beep="true" type="audio/basic" finalsilence="5s" >
      <property name="bargein" value="false"/>
      <audio expr="app_audio_path+'record.Silence.wav'">
         After the beep, please record your message.
      </audio>
      <filled>
        <assign name="doc_timer" expr="callerrecording$.duration"/>
        <assign name="app_callerRecording" expr="callerrecording"/>
        <goto next="#PostRecordMenu"/>
      </filled>
    </record>
  </form>

[support]

hi j:

all vxml <property> tags obey scope rules in the same way that variables do, but the IVR code you presented will not produce the desired effect.


This IVR code should create the behavior you are expecting:

Code: Select all

<property name="inputmodes" value="dtmf"/>

  <form id="intro">
      <field name="gather_input" type="digits?length=1">
         <prompt timeout="0s">
            You can skip this greeting by pressing any digit
         </prompt>
          <catch event= "noinput nomatch">
              <goto next= "#RecordMessage"/>
          </catch>
      </field>
      
       <block>
          <goto next= "#RecordMessage"/>
        </block>
  </form>

  <!--  RecordMessage: Record the callers information.  -->
  <form id="RecordMessage">
 
    <record name="callerrecording" beep="true" type="audio/basic" 
                finalsilence="5s" dtmfterm="true">
       <prompt>
        After the beep, please record your message.
       </prompt>
      <filled>
        you said <value expr="callerrecording"/>
      </filled>
    </record>
  </form> 

It should also be noted that the disconnect handler is scoped at the form level as well. This means the event handling will only happen if the disconnect is generated while within the form it is defined. If this is a global disconnect, be sure to define it at the document or root document level. (Not sure if this was intentional or not, but its worth mentioning as it could be a difficult bug to track down...)

Hope this helps!!

kind regards,

Plum Support