Trying to use SMS integration with Twilio in Node-RED in CF on IBM Cloud to drive individual SMS messages from mobile devices to Assistant. Here is my configuration of the Assistant v2 node:
When configured this way, the Assistant API call works and I get the Assistant conversation_start response. However, when I send a different input in reply to the conversation_start response, I once again get the conversation_start response instead of a response from the appropriate Assistant flow.
This sequence makes me think that Assistant is resetting the session each time since the response is always the conversation_start response. I never can get to any farther in Assistant.
The note at the bottom of the image makes me think I need to set msg.params.session_id, but I would also think checking Multiple Sessions and Return Context would handle setting the session_id correctly.
However, when I uncheck the Multiple Sessions box, the Assistant API call gets this error on the Assistant v2 node: "URL sessionid parameter '+1303xxxyyyy' is not a valid GUID." The '+1303xxxyyyy' is the SMS device phone number.
I'm confused on how to configure the Assistant v2 node to handle multiple sessions with the input coming from the Twilio API. Can you shed some light on this?
Can you explain further how Multiple Sessions, Return Context and msg.params.session_id work together?
Note: With Multiple Sessions and Return Context set, I also tried setting msg.user ahead of the Assistant node per @chughts January '18 reply here: https://developer.ibm.com/answers/questions/424697/watson-conversation-links-to-node-red-and-then-to/. That didn't change anything, unfortunately.
Thanks!
Read the yellow box in your picture!
Setting the multi-sessions option indicates that you will be using multiple sessions, and as such you need to supply the session id on each subsequent call. If you don’t supply the session Id then a fresh one is generated.
The session ID is not related to the context. In the Assistant V2 API, the context is not needed for input. You only need to supply context variables that your orchestration layer may have updated, nothing else is needed.
Ok, now that makes sense.
The info box says: msg.params.session_id (optional): unique identifier for the conversation session. If this field is not provided then the node will generate a new session_id and return itt as part of the response. If the node is not used in multi-session mode, then a session_id need not be provided, to reset the session_id in single-session mode send a null value as the session_id. Format: String
So, I implemented this code in a function box ahead of Assistant using the unique phone number string from the SMS Twilio session as the session_id:
msg.params = {};
msg.params.session_id = "1234567890"; // an example phone number
I'm assuming that params is an object with a "session_id":"value" pair.
Assistant now throws this error: "URL session parameter '1234567890' is not a valid GUID"
So, it appears that Assistant is looking for a string that is a GUID?
The phone number is unique and I'd like to use that as the "unique identifier".
If I can't, do you have a code sample on how you would implement providing a unique GUID for the session_id based on a unique string that I do have?
Thanks!
It’s the Watson Assistant V2 API that generates the Session ID. The service maps the context etc. With the session ID. The node returns the session ID as part of its output, and your app needs to resubmit it as part of the input.
In the V1 API the full context object was required to be submitted as part of each dialog turn. The V1 Node simplified the process by storing the context. In multi-user mode, it needs to figure out which context object to use, hence the need to supply an identifier to help the node figure out which context object to use.
In the V2 API the Assistant service is managing the context, so the node doesn't need to. The service needs to be able to figure out which context to use, and it does this by mapping to a session id. The service generates this id and returns it. The session id is required to be submitted as part of each dialog turn. In single user mode the V2 Node simplifies the process by storing the session id, but in multi-user mode the Node needs to determine which session id to pass. Instead of mapping the session id to another id, the Node expects the session id to be part of the input. If you don't supply an id, the Node gets the service to generate a new one, and returns it.
Got it. Thank you for the explanation. Working now, thanks again.
