Submit After Subdialog Sends Request To Wrong URI

[enanas]

Hi again Mr. Dirk and everyone!

As I said in the e-mail there might be a bug regarding the subdialog tag in the VXML. I believe it is using the wrong base URI of a document. I am using a JBoss Application Server to run my IVRs that were made using Avaya. Here are some examples of its behavior that I noticed:

My initial request is http://someip/Dispatcher/Start and my response is something like this:

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.1" xmlns="http://www.w3.org/2001/vxml" xml:lang="en-us">
a lot of stuff
<form id="Start">
<block>
<submit next="addLogger?___DDSESSIONID=sessionId" namelist="session___aai session___ani session___dnis session___protocolname session___protocolversion session___uui session___calltag session___channel session___vpcalledextension session___vpcoveragereason session___vpcoveragetype session___vprdnis redirectinfo___uri redirectinfo___presentationinfo redirectinfo___screeninginfo redirectinfo___reason session___sharedmode shareduui___id shareduui___value session___sessionlabel _sipcallid session___mediatype session___videoenabled session___videocodec session___videoformat session___videowidth session___videoheight session___videofps session___videobitrate session___videonearfmtp session___videofarfmtp session___ucid session___conversefirst session___conversesecond" method="post"/>
</block>
</form>
</vxml>

So I the JVXML send the second request using the base URI of this document. Second response is like this:

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.1" xmlns="http://www.w3.org/2001/vxml" xml:lang="en-us">
again a lot of stuff
<form id="PropertiesModule">
<subdialog name="PropertiesModule" src="/PropertiesTransactionModule/Start?___DDSESSIONID=sessionId&sagecall=english" method="get">
<filled>
</filled>
</subdialog>
<block>
<submit next="InitVars?___DDSESSIONID=sessionId"/>
</block>
</form>
</vxml>

So after this response the JVXML calls the subdialog first but when the subdialog ends it continues with the submit section and it wrongly sends the request using the base URI of the subdialog that it just used instead of the base URI of root document of the second response resulting in a 404 response from the server.

Possible cause of this behavior is in the FormInterpretationAlgorithm.java file. In the visitSubdialogFromItem function where the application variable is initialized it is using the variable 'context' to get it's application. Then when the document is added to the newly created application using the addDocument function it also modifies the application inside the context. This change might be causing the behavior I just mentioned.

I don't know if I should mention this here but before this issue I had the problem of never ending loops that were calling the subdialog over and over again. I did some changes in the structure and resolved the issue. I don't know if this is intended or not.

Thanks!

[schnelle]

Thanks for the good pre-analysis. I suggest to se a new Application object with the current subdiag document as root context to avoid any side effects onto resolving names. Fix is commited in branch feature/issue-162 however, I did not test it carefully, yet.

[schnelle]

Some more tests and changes done to match with the requirements specified at https://www.w3.org/TR/voicexml20/#dml1.5.2 for subdialog

A subdialog invocation occurs when a root or leaf document executes a element. As discussed in Section 2.3.4, subdialog invocation creates a new execution context. The application root document and its context in the calling document's execution context are preserved untouched during subdialog execution, and are used again once the subdialog returns. A subdialog's new execution context has its own root context and, possibly, leaf context. When the subdialog is invoked with a non-empty URI reference, the caching policy in Section 6.1.2 is used to acquire the root and leaf documents that will be used to initialize the new root and leaf contexts. If a subdialog is invoked with an empty URI reference and a fragment identifier, e.g. "#sub1", the root and leaf documents remain unchanged, and therefore the current root and leaf documents will be used to initialize the new root and leaf contexts.

Test run with the subdialog demo shows

Loading invokeDocument.vxml with the default application

    Line 2688: 2023-09-01T12:57:58,139 [e6-977f-7647dfbe9258] DEBUG  datamodel.ecmascript.EcmaScriptDataModel (   461) - created 'loadedDocumentURIs$' in scope 'APPLICATION' as an array of 1
    Line 2689: 2023-09-01T12:57:58,139 [e6-977f-7647dfbe9258] DEBUG  datamodel.ecmascript.EcmaScriptDataModel (   850) - set 'loadedDocumentURIs$[0]' to 'file:/C:/Users/dirks/git/JVoiceXML/org.jvoicexml.demo.subdialogdemo/build/resources/main/invokeSubdialog.vxml' in scope 'APPLICATION' 

Resolving the URIof the subdialog document startSubdialog.vxml with the current application

    Line 2757: 2023-09-01T12:57:58,200 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   235) - resolving URI 'startSubdialog.vxml'...
    Line 2758: 2023-09-01T12:57:58,200 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   263) - resolved to 'file:/C:/Users/dirks/git/JVoiceXML/org.jvoicexml.demo.subdialogdemo/build/resources/main/startSubdialog.vxml'

Creating a new context and application with data from startSubdialog.vxml

    Line 2760: 2023-09-01T12:57:58,201 [e6-977f-7647dfbe9258] DEBUG  .interpreter.FormInterpretationAlgorithm (  1553) - creating new context and application for subdialog
    Line 2763: 2023-09-01T12:57:58,201 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   235) - resolving URI 'file:/C:/Users/dirks/git/JVoiceXML/org.jvoicexml.demo.subdialogdemo/build/resources/main/startSubdialog.vxml'...
    Line 2764: 2023-09-01T12:57:58,201 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   249) - Can not resolve 'file:/C:/Users/dirks/git/JVoiceXML/org.jvoicexml.demo.subdialogdemo/build/resources/main/startSubdialog.vxml'. No base URI set.
    Line 2776: 2023-09-01T12:57:58,204 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   235) - resolving URI 'file:/C:/Users/dirks/git/JVoiceXML/org.jvoicexml.demo.subdialogdemo/build/resources/main/startSubdialog.vxml'...

Load startSubdialog with the subdialog context and application Line 2780: 2023-09-01T12:57:58,204 [e6-977f-7647dfbe9258] DEBUG oicexml.interpreter.JVoiceXmlApplication ( 136) - loaded documents:

    Line 2781: 2023-09-01T12:57:58,204 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   139) - - file:/C:/Users/dirks/git/JVoiceXML/org.jvoicexml.demo.subdialogdemo/build/resources/main/startSubdialog.vxml
    Line 2783: 2023-09-01T12:57:58,204 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   235) - resolving URI 'file:/C:/Users/dirks/git/JVoiceXML/org.jvoicexml.demo.subdialogdemo/build/resources/main/startSubdialog.vxml'...
    Line 2784: 2023-09-01T12:57:58,205 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   263) - resolved to 'file:/C:/Users/dirks/git/JVoiceXML/org.jvoicexml.demo.subdialogdemo/build/resources/main/startSubdialog.vxml'
    Line 2785: 2023-09-01T12:57:58,205 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   136) - loaded documents:
    Line 2786: 2023-09-01T12:57:58,205 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   139) - - file:/C:/Users/dirks/git/JVoiceXML/org.jvoicexml.demo.subdialogdemo/build/resources/main/startSubdialog.vxml

Execute the subdialog and abandon the subdialog context and focus

    Line 2857: 2023-09-01T12:57:58,383 [Thread-24           ] DEBUG  exml.interpreter.SubdialogExecutorThread (   139) - abandonned subdialog application
    Line 2917: 2023-09-01T12:58:01,133 [e6-977f-7647dfbe9258] DEBUG  voicexml.interpreter.scope.ScopeObserver (    80) - current scope stack: [SESSION, APPLICATION, DOCUMENT, DIALOG, ANONYMOUS]
    Line 2923: 2023-09-01T12:58:01,134 [e6-977f-7647dfbe9258] DEBUG  voicexml.interpreter.scope.ScopeObserver (   114) - current scope stack: [SESSION, APPLICATION, DOCUMENT, DIALOG]
    Line 2932: 2023-09-01T12:58:01,134 [e6-977f-7647dfbe9258] DEBUG  voicexml.interpreter.scope.ScopeObserver (   114) - current scope stack: [SESSION, APPLICATION, DOCUMENT]

Continue in invokeSubdialg.vxml with the previous context and application

    Line 2934: 2023-09-01T12:58:01,134 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   235) - resolving URI 'afterSubdialog.vxml'...
    Line 2935: 2023-09-01T12:58:01,134 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   263) - resolved to 'file:/C:/Users/dirks/git/JVoiceXML/org.jvoicexml.demo.subdialogdemo/build/resources/main/afterSubdialog.vxml'
    Line 2946: 2023-09-01T12:58:01,137 [e6-977f-7647dfbe9258] DEBUG  oicexml.interpreter.JVoiceXmlApplication (   235) - resolving URI 'file:/C:/Users/dirks/git/JVoiceXML/org.jvoicexml.demo.subdialogdemo/build/resources/main/afterSubdialog.vxml'...

Please, confirm if this resolves the issue on your side.

[enanas]

I just tested it and it works, thank you for the quick response! A small note on the infinite loop problem that I mentioned at the end of the issue: it was because I forgot to set the scope of the DataModel.

[schnelle]

Thanks for testing.