18 Jul
2009
18 Jul
'09
9:18 p.m.
i have now managed to get all my stuff working using sr except
t_uac_dlg. t_uac_dlg is not working because for some reason sr tm
module does not implement t_uac_dlg and mi_rpc tells "async mi cmd not
implemented yet".
i would prefer native support of t_uac_dlg in tm module, because the
idea was that sr will use ser tm module. if t_uac is difficult to
implement in ser tm module or if that would still not make t_uac_dlg to
work via rpc, then i guess i need to wait until mi_rpc supports async mi
functions.
otherwise things thus look pretty good to me. thanks for your efforts.
-- juha
18 Jul
18 Jul
9:57 p.m.
On Jul 18, 2009 at 22:18, Juha Heinanen <jh(a)tutpro.com> wrote:
i have now managed to get all my stuff working using
sr except
t_uac_dlg. t_uac_dlg is not working because for some reason sr tm
module does not implement t_uac_dlg and mi_rpc tells "async mi cmd not
implemented yet".
i would prefer native support of t_uac_dlg in tm module, because the
idea was that sr will use ser tm module. if t_uac is difficult to
implement in ser tm module or if that would still not make t_uac_dlg to
work via rpc, then i guess i need to wait until mi_rpc supports async mi
functions.
t_uac_dlg was removed long time ago from ser (that's also were
kamailio/openser inherited it from). There were 2 versions one working
with the fifo and another one with unixsocks, but both were removed when
we switched to RPC.
IIRC the idea was to make a separate module implementing it, but we
stopped when sems got its own sip stack (sems was the only known user).
t_uac exists in sr tm and is exported by the tm api. t_uac_dlg is/was
just a wrapper reading and writing to fifo/unixsock/mi and then calling
t_uac.
It should be possible to revive the t_uac_dlg implementation in
a separate module but the problem is that proper async support is easy to
implement only using the old fifo (and passing a "reply" fifo) or
datagram sockets (the async support in mi_xmlrpc is a joke: it just
waits in a loop, _polling_ a shared memory variable until someone writes
it or timeouts and then sends the xmlrpc reply).
That being said there is some work on an application server interface
using the binrpc protocol (see ftp://ftp.iptel.org/pub/sug/sersum.pdf
and http://tracker.iptel.org/browse/SER-347), which far exceeds t_uac_dlg
needs. From what I know all the required tm changes are in-place, we
only have to wait for Bogdan Pintea to commit the rest of it.
otherwise things thus look pretty good to me. thanks for your efforts.
Thanks a lot for testing.
Andrei
11:35 p.m.
On 18.07.2009 21:57 Uhr, Andrei Pelinescu-Onciul wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com/index.php/sip-router-bootcamp/
On Jul 18, 2009 at 22:18, Juha Heinanen
<jh(a)tutpro.com> wrote:
> i have now managed to get all my stuff working using sr except
> t_uac_dlg. t_uac_dlg is not working because for some reason sr tm
> module does not implement t_uac_dlg and mi_rpc tells "async mi cmd not
> implemented yet".
>
> i would prefer native support of t_uac_dlg in tm module,
there is an alternative that you can use: dlg_bridge from K dialog module:
http://sip-router.org/docbook/sip-router/branch/master/modules_k/dialog/dia…
It does the c2d logic internally. The difference is that you do not get
feedback from all requests/replies of c2d flow. It initiate the c2d
process and returns - it is sync mode and easier to use via MI (just one
command).
You need just to create the table, load the module and set few
parameters, you don't have to track calls with dialog module, so no
runtime overload.
Cheers,
Daniel
because the
idea was that sr will use ser tm module. if t_uac is difficult to
implement in ser tm module or if that would still not make t_uac_dlg to
work via rpc, then i guess i need to wait until mi_rpc supports async mi
functions.
t_uac_dlg was removed long time ago from ser (that's also were
kamailio/openser inherited it from). There were 2 versions one working
with the fifo and another one with unixsocks, but both were removed when
we switched to RPC.
IIRC the idea was to make a separate module implementing it, but we
stopped when sems got its own sip stack (sems was the only known user).
t_uac exists in sr tm and is exported by the tm api. t_uac_dlg is/was
just a wrapper reading and writing to fifo/unixsock/mi and then calling
t_uac.
It should be possible to revive the t_uac_dlg implementation in
a separate module but the problem is that proper async support is easy to
implement only using the old fifo (and passing a "reply" fifo) or
datagram sockets (the async support in mi_xmlrpc is a joke: it just
waits in a loop, _polling_ a shared memory variable until someone writes
it or timeouts and then sends the xmlrpc reply).
That being said there is some work on an application server interface
using the binrpc protocol (see ftp://ftp.iptel.org/pub/sug/sersum.pdf
and http://tracker.iptel.org/browse/SER-347), which far exceeds t_uac_dlg
needs. From what I know all the required tm changes are in-place, we
only have to wait for Bogdan Pintea to commit the rest of it.
otherwise things thus look pretty good to me.
thanks for your efforts.
Thanks a lot for testing.
Andrei
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
11:38 p.m.
On 18.07.2009 23:35 Uhr, Daniel-Constantin Mierla wrote:
On 18.07.2009 21:57 Uhr, Andrei Pelinescu-Onciul wrote:
actually, with db_mode=0, there should be no
need of db table.
Cheers,
Daniel
On Jul 18, 2009 at 22:18, Juha Heinanen
<jh(a)tutpro.com> wrote:
> i have now managed to get all my stuff working using sr except
> t_uac_dlg. t_uac_dlg is not working because for some reason sr tm
> module does not implement t_uac_dlg and mi_rpc tells "async mi cmd not
> implemented yet".
>
> i would prefer native support of t_uac_dlg in tm module,
there is an alternative that you can use: dlg_bridge from K dialog
module:
http://sip-router.org/docbook/sip-router/branch/master/modules_k/dialog/dia…
It does the c2d logic internally. The difference is that you do not
get feedback from all requests/replies of c2d flow. It initiate the
c2d process and returns - it is sync mode and easier to use via MI
(just one command).
You need just to create the table, load the module and set few parameters, you don't
have to track calls
with dialog module, so no runtime overload.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/index.php/sip-router-bootcamp/
because
the
idea was that sr will use ser tm module. if t_uac is difficult to
implement in ser tm module or if that would still not make t_uac_dlg to
work via rpc, then i guess i need to wait until mi_rpc supports
async mi
functions.
t_uac_dlg was removed long time ago from ser (that's also were
kamailio/openser inherited it from). There were 2 versions one working
with the fifo and another one with unixsocks, but both were removed when
we switched to RPC.
IIRC the idea was to make a separate module implementing it, but we
stopped when sems got its own sip stack (sems was the only known user).
t_uac exists in sr tm and is exported by the tm api. t_uac_dlg is/was
just a wrapper reading and writing to fifo/unixsock/mi and then calling
t_uac.
It should be possible to revive the t_uac_dlg implementation in a
separate module but the problem is that proper async support is easy to
implement only using the old fifo (and passing a "reply" fifo) or
datagram sockets (the async support in mi_xmlrpc is a joke: it just
waits in a loop, _polling_ a shared memory variable until someone writes
it or timeouts and then sends the xmlrpc reply).
That being said there is some work on an application server interface
using the binrpc protocol (see ftp://ftp.iptel.org/pub/sug/sersum.pdf
and http://tracker.iptel.org/browse/SER-347), which far exceeds
t_uac_dlg
needs. From what I know all the required tm changes are in-place, we
only have to wait for Bogdan Pintea to commit the rest of it.
otherwise things thus look pretty good to me.
thanks for your efforts.
Thanks a lot for testing.
Andrei
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
19 Jul
19 Jul
9:33 a.m.
Daniel-Constantin Mierla writes:
there is an alternative that you can use: dlg_bridge
from K dialog module:
http://sip-router.org/docbook/sip-router/branch/master/modules_k/dialog/dia…
It does the c2d logic internally. The difference is that you do not get
feedback from all requests/replies of c2d flow. It initiate the c2d
process and returns - it is sync mode and easier to use via MI (just one
command).
daniel,
i don't think that current version of dlg_bridge is a valid replacement
for t_uac_dlg. dlg_bridge has these params:
from - SIP address to initiate the call
to - SIP address to refer 'from' to
op (optional) - outbound proxy SIP address
whereas t_uac_dlg additionally has socket param, which i fill from
location table socket column of the phone to be used for click2dial.
further, i use aor of the phone in To header and contact in
Request-URI.
please add the missing params to dlg_bridge and i'll give it a try.
i haven't checked sems yet, but i suspect that its click2dial app (if
one exists) does not have support for all the necessary params either.
-- juha
10:48 a.m.
Juha Heinanen writes:
please add the missing params to dlg_bridge and
i'll give it a try.
i didn't find socket param in t_request call that dialog module
dlg_bridge function executes:
ret = d_tmb.t_request(&s_method, /* Type of the message */
&dtc->from, /* Request-URI (To) */
&dtc->from, /* To */
&dlg_bridge_controller, /* From */
&s_hdrs, /* Optional headers including CRLF */
&s_body, /* Message body */
(op!=NULL && op->len>0)?op:NULL, /* outbound uri */
dlg_bridge_tm_callback, /* Callback function */
(void*)(long)dtc /* Callback parameter */
);
if i remember correctly, socket needs to be specified given if phone
that is used for click-to-dial is behind nat.
-- juha
11:04 a.m.
On 19.07.2009 10:48 Uhr, Juha Heinanen wrote:
Juha Heinanen writes:
it is not one-to-one replacement to MI uac tm
function. This one will go
via usrloc and everything is resolved there - you have to provide the
AoRs of caller and callee. It can work even if you use a dedicated proxy
instance only for c2d.
Cheers,
Daniel
please add the missing params to dlg_bridge and
i'll give it a try.
i didn't find socket param in t_request call that
dialog module
dlg_bridge function executes:
ret = d_tmb.t_request(&s_method, /* Type of the message */
&dtc->from, /* Request-URI (To) */
&dtc->from, /* To */
&dlg_bridge_controller, /* From */
&s_hdrs, /* Optional headers including CRLF */
&s_body, /* Message body */
(op!=NULL && op->len>0)?op:NULL, /* outbound uri */
dlg_bridge_tm_callback, /* Callback function */
(void*)(long)dtc /* Callback parameter */
);
if i remember correctly, socket needs to be specified given if phone
that is used for click-to-dial is behind nat.
-- juha
--
Daniel-Constantin Mierla
http://www.asipto.com/index.php/sip-router-bootcamp/
11:20 a.m.
Daniel-Constantin Mierla writes:
it is not one-to-one replacement to MI uac tm
function. This one will go
via usrloc and everything is resolved there - you have to provide the
AoRs of caller and callee. It can work even if you use a dedicated proxy
instance only for c2d.
if user has several phones registered for an AoR, my web app allows the
user to choose, which one to use for the click-to-dial call. if i use
dlg-bridge, sems, or some other external app, this capability is lost.
instead, when user clicks, all phones that have registered that AoR
start to ring, which is not a good thing.
i can try to explain to users that unfortunately this new proxy cannot
anymore support phone selection when making a click-to-dial call. that
may not be acceptable in some office environments and, if so, then i
have lost the upgrade game and need to keep on using k or opensips in
those environments.
-- juha
11:37 a.m.
On 19.07.2009 11:28 Uhr, Juha Heinanen wrote:
is pua_publish provided by pua_mi module also not
supported by mi_rpc?
Juha, MI interface is the same and you can keep using it. If you look
for new features or improvements by new modules, the you can contribute
everything worth for you.
If there is some parameter/function not ported yet from K core or tm,
feel free to do it, most of the cases is copy&paste with some update of
functions signatures.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/index.php/sip-router-bootcamp/
11:44 a.m.
Daniel-Constantin Mierla writes:
If there is some parameter/function not ported yet
from K core or tm,
feel free to do it, most of the cases is copy&paste with some update of
functions signatures.
based on andrei's message, i don't think he would be very happy if i
would add t_uac_dlg to tm module.
-- juha
11:53 a.m.
On 19.07.2009 11:44 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
this MI function is already in sip router git, in tmx module:
http://sip-router.org/docbook/sip-router/branch/master/modules_k/tmx/tmx.ht…
Just not available over RPC interface, but via the other MI transports.
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/index.php/sip-router-bootcamp/
If there is some parameter/function not ported
yet from K core or tm,
feel free to do it, most of the cases is copy&paste with some update of
functions signatures.
based on andrei's message, i don't think he would be very happy if i
would add t_uac_dlg to tm module.
12:26 p.m.
On Sun, Jul 19, 2009 at 11:44 AM, Juha Heinanen<jh(a)tutpro.com> wrote:
Daniel-Constantin Mierla writes:
Adding t_uac_dlg to the tm module is not an issue. As Andrei mentioned
there were two separate implementations of the function, one for the
fifo interface and one for the unixsock interface. This was just a
wrapper over some other functions that are still present in the
current version of tm module.
What we need to figure out is how to implement something like
callbacks or asynchronous calls with XML-RPC. Suggestions here are
welcome.
Jan.
If there is some parameter/function not ported
yet from K core or tm,
feel free to do it, most of the cases is copy&paste with some update of
functions signatures.
based on andrei's message, i don't think he would be very happy if i
would add t_uac_dlg to tm module.
11:52 a.m.
On 19.07.2009 11:20 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The new proxy supports it as the old ones did. The tmx module has the MI
function you need and you can keep using the old code you have via
classic MI transports, with same signature, a.s.o. So kamailio or sip
router is the same for this particular case.
Daniel
Daniel-Constantin Mierla
http://www.asipto.com/index.php/sip-router-bootcamp/
it is not one-to-one replacement to MI uac tm
function. This one will go
via usrloc and everything is resolved there - you have to provide the
AoRs of caller and callee. It can work even if you use a dedicated proxy
instance only for c2d.
if user has several phones registered for an AoR, my web app allows the
user to choose, which one to use for the click-to-dial call. if i use
dlg-bridge, sems, or some other external app, this capability is lost.
instead, when user clicks, all phones that have registered that AoR
start to ring, which is not a good thing.
i can try to explain to users that unfortunately this new proxy cannot
anymore support phone selection when making a click-to-dial call.
11:55 a.m.
Daniel-Constantin Mierla writes:
The new proxy supports it as the old ones did. The tmx
module has the MI
function you need and you can keep using the old code you have via
classic MI transports, with same signature, a.s.o. So kamailio or sip
router is the same for this particular case.
the idea of having two management interfaces to the same proxy is not
very appealing. if i need to do that i can as well keep on using two
proxies.
-- juha
noon
On 19.07.2009 11:55 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
you can keep using MI like so far, as I do, I don't see where is the
problem right now. There is no difference between kamailio 1.5 and sip
router. If you want to migrate to rpc or something else, then it is the
place where you have to contribute to fit your needs.
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/index.php/sip-router-bootcamp/
The new proxy supports it as the old ones did.
The tmx module has the MI
function you need and you can keep using the old code you have via
classic MI transports, with same signature, a.s.o. So kamailio or sip
router is the same for this particular case.
the idea of having two management interfaces to the same proxy is not
very appealing. if i need to do that i can as well keep on using two
proxies.
12:09 p.m.
Daniel-Constantin Mierla writes:
you can keep using MI like so far, as I do, I
don't see where is the
problem right now. There is no difference between kamailio 1.5 and sip
router. If you want to migrate to rpc or something else, then it is the
place where you have to contribute to fit your needs.
i have already migrated to rpc, because it has much more flexible xmlrpc
interface. i understand that you keep on using mi like before, because
you don't use xmlrpc.
also, i use ser domain module and it only supports rpc interface. of
course, i could go and add mi support to ser domain module, but that
would be waste of time.
one possibility so solve this might be to add a contact param to lookup
function. if given, it would try to find matching contact and incldue
only that in destination set. or then try to remove in the script
unwanted contacts from the destination set.
-- juha
20 Jul
20 Jul
9:49 a.m.
Daniel-Constantin Mierla schrieb:
On 18.07.2009 21:57 Uhr, Andrei Pelinescu-Onciul wrote:
from docu:
On Jul 18, 2009 at 22:18, Juha Heinanen
<jh(a)tutpro.com> wrote:
> i have now managed to get all my stuff working using sr except
> t_uac_dlg. t_uac_dlg is not working because for some reason sr tm
> module does not implement t_uac_dlg and mi_rpc tells "async mi cmd not
> implemented yet".
>
> i would prefer native support of t_uac_dlg in tm module,
there is an alternative that you can use: dlg_bridge from K dialog module:
http://sip-router.org/docbook/sip-router/branch/master/modules_k/dialog/dia…
Bridge 'from' SIP address to 'to' SIP
address via outbound proxy 'op'.
by no means I would have guessed that this means "click-2-dial". I think
this function needs some more documentation.
regards
klaus
10:42 a.m.
On 20.07.2009 9:49 Uhr, Klaus Darilion wrote:
Daniel-Constantin Mierla schrieb:
ok. I that time was also a news
notification email. Anyhow, for docs is
all the time space, feel free to suggest and/or add.
Thanks,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/index.php/sip-router-bootcamp/
On 18.07.2009 21:57 Uhr, Andrei Pelinescu-Onciul wrote:
from docu:
On Jul 18, 2009 at 22:18, Juha Heinanen
<jh(a)tutpro.com> wrote:
> i have now managed to get all my stuff working using sr except
> t_uac_dlg. t_uac_dlg is not working because for some reason sr tm
> module does not implement t_uac_dlg and mi_rpc tells "async mi cmd not
> implemented yet".
>
> i would prefer native support of t_uac_dlg in tm module,
there is an alternative that you can use: dlg_bridge from K dialog
module:
http://sip-router.org/docbook/sip-router/branch/master/modules_k/dialog/dia…
Bridge 'from' SIP address to 'to'
SIP address via outbound proxy 'op'.
by no means I would have guessed that this means "click-2-dial". I
think this function needs some more documentation.
19 Jul
19 Jul
1:40 p.m.
Andrei Pelinescu-Onciul writes:
That being said there is some work on an application
server interface
using the binrpc protocol (see ftp://ftp.iptel.org/pub/sug/sersum.pdf
and http://tracker.iptel.org/browse/SER-347), which far exceeds t_uac_dlg
needs. From what I know all the required tm changes are in-place, we
only have to wait for Bogdan Pintea to commit the rest of it.
sounds good if it allows to select which contact of an AoR to send the
invite to. that cannot be done using external sip clients like sems.
i forgot to mention that my click-to-dial app only allows the user to
chooses among phones that support refer method. daniel's suggestion to
use dlg_bridge thus suffers from two short comings as a means to
implement click-to-dial app:
- cannot choose which phone rings
- a phone that is answered may not support refer method making the call fail
-- juha
6:27 p.m.
Hi Juha,
o Juha Heinanen [07/19/09 13:40]:
Andrei Pelinescu-Onciul writes:
if you can
get the contact to send the INVITE to into your web app, it
is for sure possible to get it into an external app server like sems,
where you set it as dlg.next_hop, and your outbound proxy selects the
correct socket for it.
Stefan
--
Stefan Sayer
VoIP Services
stefan.sayer(a)iptego.com
www.iptego.com
IPTEGO GmbH
Wittenbergplatz 1
10789 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
That being said there is some work on an
application server interface
using the binrpc protocol (see ftp://ftp.iptel.org/pub/sug/sersum.pdf
and http://tracker.iptel.org/browse/SER-347), which far exceeds t_uac_dlg
needs. From what I know all the required tm changes are in-place, we
only have to wait for Bogdan Pintea to commit the rest of it.
sounds good if it allows to select which contact of an AoR to send the
invite to. that cannot be done using external sip clients like sems.
6:41 p.m.
Stefan Sayer writes:
if you can get the contact to send the INVITE to into
your web app, it
is for sure possible to get it into an external app server like sems,
where you set it as dlg.next_hop, and your outbound proxy selects the
correct socket for it.
stefan,
i don't think there is a mechanism to automatically select a correct
socket. socket info is in location table along with contact uri and it
gets set correctly, when lookup function is called or when given
manually as parameter to t_uac_dlg function.
if i just make a call
INVITE contact-uri
using my sip proxy as outbound proxy, no lookup function will be called
and no socket info will get set.
-- juha
6:49 p.m.
o Juha Heinanen [07/19/09 18:41]:
Stefan Sayer writes:
hm, i guess a lookup_socket function could be useful to add to sr.
Stefan
--
Stefan Sayer
VoIP Services
stefan.sayer(a)iptego.com
www.iptego.com
IPTEGO GmbH
Wittenbergplatz 1
10789 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
if you can get the contact to send the INVITE to
into your web app, it
is for sure possible to get it into an external app server like sems,
where you set it as dlg.next_hop, and your outbound proxy selects the
correct socket for it.
stefan,
i don't think there is a mechanism to automatically select a correct
socket. socket info is in location table along with contact uri and it
gets set correctly, when lookup function is called or when given
manually as parameter to t_uac_dlg function.
if i just make a call
INVITE contact-uri
using my sip proxy as outbound proxy, no lookup function will be called
and no socket info will get set.
12:20 p.m.
Juha,
On Sat, Jul 18, 2009 at 9:18 PM, Juha Heinanen<jh(a)tutpro.com> wrote:
i have now managed to get all my stuff working using
sr except
t_uac_dlg. t_uac_dlg is not working because for some reason sr tm
module does not implement t_uac_dlg and mi_rpc tells "async mi cmd not
implemented yet".
i would prefer native support of t_uac_dlg in tm module, because the
idea was that sr will use ser tm module. if t_uac is difficult to
implement in ser tm module or if that would still not make t_uac_dlg to
work via rpc, then i guess i need to wait until mi_rpc supports async mi
functions.
otherwise things thus look pretty good to me. thanks for your efforts.
First of all, thanks a lot for your extremely useful testing and integration
efforts.
As far as I can remember, t_uac_dlg (and perhaps other tm functions that are
missing in the tm rpc interface) were not implemented because there was no
way of calling asynchronous callbacks when the function call completes. This
was easy to do with the old fifo and unixsock interfaces, but more complicated
with the xmlrpc interface.
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?
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)?
Jan.
1:45 p.m.
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.
-- juha
20 Jul
20 Jul
10: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.
22 Jul
22 Jul
9: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
10:09 a.m.
On Jul 22, 2009 at 10:37, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
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
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.
11:28 a.m.
Andrei Pelinescu-Onciul writes:
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).
great. i would only need it for xmlrpc. for testing purposes ctl would
be also nice.
-- juha
19 Jul
19 Jul
6:35 p.m.
o Jan Janak [07/19/09 12:20]:
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?
afaiu this type of callbacks
is common for rest- and rest-like APIs. in
other rpc protocols like jsonrpc, asynchronous notifications are
possible (i.e. not only client-server request-response, but more peer).
binrpc has the explicit registered callbacks.
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 think this makes it much more
difficult to use because you can't use a
standard client.
Stefan
5418
days inactive
5422
days old
29 comments
6 participants
participants (6)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com -
Klaus Darilion -
Stefan Sayer