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
Export vars #68
Export vars #68
Conversation
Would you be able to apply the exported vars to the client record instead of the call record? The client record already has support for a list of arbitrary key/values, and is passed around with the call. |
Yep, I can try. You think about adding extra field export_vars or adding those variables to field options? |
Also do you hae any idea why I need to uri_decode headers? |
SIP headers are very much like HTTP headers, so I suspect FreeSWITCH is encoding the data to be complient. This is just a hypothesis, I'd have to research to find out what's up. Also, mochiweb has urlencode and unquote in the mochi_util module. |
Nope, it's not an issue of FreeSWITCH - if the call is passed directly (without OpenACD) it is encoded properly (once). When it gets into OpenACD it gets re-encoded (so I have to decode in OpenACD what I receive in FS or decode twice in SIP client). |
This has be implemented in v2, putting the exported vars in the ring channel as well as the client options passed to the agent UI. The URI decoding is not yet implemented as I've yet to find a case the seems to break. Can you supply a dialplan the shows the need for double-decode? |
I see you already implemented passing exported variables from FS to agent leg in ba47ac0 The example of double-encoding is:
(P-Attach is encodeURIComponent(JSON.serialize(some_var)), where some_var={a:"b",c:{d:"e",f:"g"}}) In freeswitch_media.erl I have:
and in full.log I have:
|
Previous commit only retrieved the exported variables values from IVR leg.
This exports those variables to agent leg.
A few notes (should probably be split into different commits):