Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Grammar failing in AdhearsionIVR #616

Open
lpradovera opened this issue Dec 15, 2016 · 6 comments
Open

Grammar failing in AdhearsionIVR #616

lpradovera opened this issue Dec 15, 2016 · 6 comments

Comments

@lpradovera
Copy link
Member

Hello,
this is a pretty weird issue I have. Apparently, the same grammar works if generated and used by #ask, but does not if used inside AdhearsionIVR.

Working logs: https://gist.github.com/lpradovera/d60a9b127c3dc12cf5bf422c616652bd
Failing logs: https://gist.github.com/lpradovera/ec6341ab0e9d84a032d9c98c7f3b72cd

@bklang
Copy link
Member

bklang commented Dec 15, 2016

The error here appears to be unrelated to the grammar: the call was terminated because the SIP extension was not registered:

2016-12-15 07:41:20.571664 [NOTICE] switch_ivr_originate.c:2841 Cannot create outgoing channel of type [sofia] cause: [USER_NOT_REGISTERED]
2016-12-15 07:41:20.571664 [DEBUG] switch_ivr_originate.c:3829 Originate Resulted in Error Cause: 606 [USER_NOT_REGISTERED]
2016-12-15 07:41:20.571664 [DEBUG] mod_rayo.c:2816 dial: Failed to originate call: USER_NOT_REGISTERED
# ... SNIP
<end xmlns='urn:xmpp:rayo:1'><error platform-code='20'/></end><delay xmlns='urn:xmpp:delay' stamp='2016-12-15T15:41:20Z'/></presence>

@lpradovera
Copy link
Member Author

Yes, but that is not related (I know that channel does not exist). I'll recheck without dialing first, but even if that works, it is still a bug, just not the same one :)

@lpradovera
Copy link
Member Author

@lpradovera
Copy link
Member Author

Code I was using to reproduce, for reference:

  def run
    answer

    dtmf_grammar = RubySpeech::GRXML.draw root: 'main_menu_dtmf', mode: :dtmf, tag_format: 'semantics/1.0.2006' do
        rule id: 'main_menu_dtmf' do
          one_of do
            item { string '1'; tag { string 'out = "missing"' } }
            item { string '2'; tag { string 'out = "wet"' } }
            item { string '3'; tag { string 'out = "damaged"' } }
            item { string '8'; tag { string 'out = "repeat"' } }
            item { string '0'; tag { string 'out = "other"' } }
            item { string '*'; tag { string 'out = "other"' } }
          end
        end
      end

voice_grammar = RubySpeech::GRXML.draw root: 'yes_no', mode: :voice, language: 'en-US', tag_format: 'semantics/1.0.2006' do
        rule id: 'yes_no' do
          one_of do
            item do
              one_of do
                item { string 'yes' }
                item { string 'yep' }
                item { string 'yeah' }
                item { string 'correct' }
              end
              tag { string 'out = "yes"' }
            end
            item do
              one_of do
                item { string 'no' }
                item { string 'nope' }
                item { string 'nah' }
                item { string 'false' }
                item { string 'assistance' }
                item { string 'operator' }
                item { string 'representative' }
              end
              tag { string 'out = "no"' }
            end
          end
        end
      end

    result = ask "Enter your favorite number", grammar: [voice_grammar, dtmf_grammar], mode: :voice
    logger.debug result
    hangup
  end
end

@lpradovera
Copy link
Member Author

From various conversations and digging, it does look like this is a problem with FreeSWITCH not supporting mixed mode grammars. I am just looking for a confirmation on that so we can tackle possible fixes.

@lpradovera
Copy link
Member Author

This issue is caused by incorrect mod_unimrcp configuration in FreeSWITCH plus a minor bug in there. Not having telephone-event in the codecs for the MRCP profile causes DTMF not to be sent.
That would have fixed the issue if not for the fact that the module has a small bug in the codec parsing, where you also need to add PCMA to the codec line, this way:

<param name="codecs" value="PCMU PCMA telephone-event"/>

This allows LumenVox to receive the DTMF and parse it in mixed mode.

The other side of this is that Adhearsion must pass any as the recognition mode, which requires a change to AdhearsionIVR which I will implement later (issue is here adhearsion/adhearsion-ivr#25)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants