How Do You Assume A Session From Event Gateways?

Question

I am using event gateways to send and receive via SMS, IM,
and Email. I can go back and forth just fine, and if the client
initiates the session, session persistence is not a problem.
Sometimes, though, we need the server to initiate the session
and the client to assume that session so we don't have to
re-establish the thread before we move on.
For example, if the client says "Approve John Doe" for
something, the bot can respond with "John Doe found. Reply with A
for admin rights, W for web rights", and so on. Because the client
established the session, replies are cemented in the bots brain so
they know if an "A" is returned, it will give John Doe Admin
access.
The trouble is if the SERVER initiates the call to the IM
Client: "This is the server speaking. John Doe is attempting to
access the double-secret files. Reply with A to Allow or X to send
10,000 volts to their computer". Reply with A and the bot will
respond with, basically, "request unknown" because the client
actually initiated a new session and nothing the server said was
heard or can be viewed by the client.
When the server creates a session in the event gateway, there
also appears to be no sessionid, cfid, or cftoken. Especially for
SMS, it's difficult to pass a UUID or specially coded variable for
the client to use to at least search and retrieve the particulars
of the event.
So, how does one get a CLIENT IM, Email or SMS to assume the
Session from the server?
Alternative solutions welcomed!
RLS

Answer 1

BKBK,
Thank you for your response. That does adequately cover the
client-originated sessions, but still leaves the ability I am
looking for unavailable.
It did serve to definitively answer my most pressing
question, however, with this statement:
Note: ColdFusion cannot create a session if an initiator
application uses a SendGatewayMessage method to start an
interaction with a client, such as an SMS user. In this case, the
sending code must keep track (for example, in a database) of the
messages it sends and their destinations. When a response event
arrives, it can look up the origniatorID to determine whether it
was in response to an outgoing message.
I will play around with the Application scope to see if there
might be a workable solution there.
RLS