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
On Jul 18, 2009 at 22:18, Juha Heinanen jh@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
On 18.07.2009 21:57 Uhr, Andrei Pelinescu-Onciul wrote:
On Jul 18, 2009 at 22:18, Juha Heinanen jh@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/dial...
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 18.07.2009 23:35 Uhr, Daniel-Constantin Mierla wrote:
On 18.07.2009 21:57 Uhr, Andrei Pelinescu-Onciul wrote:
On Jul 18, 2009 at 22:18, Juha Heinanen jh@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/dial...
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,
actually, with db_mode=0, there should be no need of db table.
Cheers, Daniel
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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/dial...
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
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
On 19.07.2009 10:48 Uhr, Juha Heinanen wrote:
Juha Heinanen writes:
please add the missing params to dlg_bridge and i'll give it a try.
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
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 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
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 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
On 19.07.2009 11:44 Uhr, Juha Heinanen wrote:
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.
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.htm...
Just not available over RPC interface, but via the other MI transports.
Daniel
On Sun, Jul 19, 2009 at 11:44 AM, Juha Heinanenjh@tutpro.com wrote:
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.
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.
On 19.07.2009 11:20 Uhr, Juha Heinanen wrote:
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.
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/
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
On 19.07.2009 11:55 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.
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.
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 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
Daniel-Constantin Mierla schrieb:
On 18.07.2009 21:57 Uhr, Andrei Pelinescu-Onciul wrote:
On Jul 18, 2009 at 22:18, Juha Heinanen jh@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/dial...
from docu:
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
On 20.07.2009 9:49 Uhr, Klaus Darilion wrote:
Daniel-Constantin Mierla schrieb:
On 18.07.2009 21:57 Uhr, Andrei Pelinescu-Onciul wrote:
On Jul 18, 2009 at 22:18, Juha Heinanen jh@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/dial...
from docu:
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.
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
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
Hi Juha,
o Juha Heinanen [07/19/09 13:40]:
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.
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 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
o Juha Heinanen [07/19/09 18:41]:
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.
hm, i guess a lookup_socket function could be useful to add to sr.
Stefan
Juha,
On Sat, Jul 18, 2009 at 9:18 PM, Juha Heinanenjh@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.
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
On Jul 19, 2009 at 14:45, Juha Heinanen jh@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
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
On Jul 22, 2009 at 10:37, Juha Heinanen jh@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
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
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
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com -
Klaus Darilion -
Stefan Sayer