[sr-dev] almost ok with testing

[Andrei Pelinescu-Onciul]

On Jul 22, 2009 at 10:37, Juha Heinanen <jh at tutpro.com> wrote:
> 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.

Ok, I'll add async support (in fact delayed reply support since it's not
true async), at least to xmlrpc (turns out that it's quite easy since
xmlrpc reuses sr tcp). For ctl/binrpc it would be easy for datagram
sockets (udp or unix datagram socket) and more difficult (but possible)
for stream sockets (tcp or unix stream).
However it might take a while until there will be a workable version.

Andrei