22 Jul
2009
22 Jul
'09
10:37 a.m.
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