Andrei Pelinescu-Onciul writes:
You do realise that this would block one of your web server's processes/threads for as long as it takes to get a final reply back? (depending on the tm timeouts, this could mean 2 or 3 minutes!)
yes, and that indeed may be a problem on a busy web server, but is usually ok in enterprise environment.
Do you need to know the final reply or a fire & forget t_uac_dlg version will do (the web app will not know if the call completed successfully or not)?
in case of click-to-dial, there is three requests involved: invite, if 200 ok, followed by refer, if 200 ok, followed by bye.
so the answer is that the web app need to know about success of failure of at least the first two t_uac_dlg calls unless it could give sr only one command that then internally issues all three requests.
looks like dlg_bridge mi command could be used by web server to implement to click-to-dial as a fire and forget process. but in order for dlg_bridge to be useful to me, it at least would need to accept an additional headers parameter, where i place information about what contact to use.
-- juha