20 Jul
2009
20 Jul
'09
4:39 a.m.
On Jul 19, 2009 at 14:45, Juha Heinanen <jh(a)tutpro.com> wrote:
Jan Janak 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!)
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)?
Andrei
I think that the biggest problem is to decide how
do we want to do something
like this with the XML-RPC interface? Should we make the XML-RPC
client announce an IP address and port number for incoming XML-RPC
methods to the server and let the SIP server do a XML-RPC method call
on the client?
jan,
in click-to-dial app, user's web browser sends request to web server,
which in turn generates xmlrcp requests (invite, refer, bye) to sip
proxy and responds to user when the last xmlrpc request has terminated.
using normal web programming means, i don't know how web server could
respond immediately and then later inform the user about the status of
the operation.
Or should we perhaps extend XML-RPC in a non
standard way and
introduce something like provisional replies in SIP? (i.e. first the
server would send a 100 to notify the client that the request is
being processed and then send a 200 to notify the client that the
request was finished)?
i have seen xmlrpc server responding with 100 trying. i think there is
a http header or parameter that client can use to tell if it wants to
receive provisional responses or not. however, i don't see how
provisional responses would help here.
from user's point of view, the best solution would be such where sr
xmlrcp server would be waken up by tm module when final response to the
issued sip request has arrived after which the server would respond to
the xmlrpc client.