[sr-dev] almost ok with testing

[Andrei Pelinescu-Onciul]

On Jul 19, 2009 at 14:45, Juha Heinanen <jh at tutpro.com> wrote:
> Jan Janak writes:
> 
>  > 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.

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