On 01/01/2010 12:24 PM, Antonio Goméz Soto wrote:
So, yes, you
could hack the source to inject messages asynchronously.
But when you do that, you no longer have a proxy, but something else, so
it really comes down to (a) what you want and (b) what the product is
intended to be. At the moment - several clever hacks notwithstanding,
and some UAS functionality (e.g. registrar) notwithstanding as well -
it's a proxy. As long as the intent of the product is to continue to be
a proxy, it is largely limited to the sort of things a proxy can do,
formally speaking.
And do you think the Kamailio maintainers oppose extending the
functionality in this direction?
I think the general answer is yes, but the specific answer tends to be
no in some very particular scenarios. There have been a number of
apostasies from proxy purity in the past; off the top of my head:
* Dialog timeout, dialog bridge and dialog refer;
* t_uac_dlg (tm);
* uac_req_send() (uac)
It is obvious that the wishes of the proxy god are not always honoured
here.
But the existence of these notwithstanding, the question is whether
Kamailio is the appropriate tool for extensive request intermediation
in principle. I would say it is not. The above features provide a
crude facility for originating requests from the MI interface, but it
requires invocation via the command line and is not part of the normal
event loop and/or state machine. On top of that, it would be
difficult - though perhaps not impossible - to use these basic request
construction facilities to construct sequential in-dialog requests
(such as re-INVITEs) that contain ALL the appropriate attributes
required of them, since no other supporting functionality is provided
to keep track of and easily expose state for all of them. These
features are intended for certain very narrow scenarios, not a
reflection of larger accommodations toward UAC behaviour as an
all-encompassing design principle.
Few questions have black-and-white answers; it's simply a matter of
degree to which the design and architecture of something is suitable
for a particular class of tasks. In the case of things like
re-INVITEs, I think the suitability is very low.
Any suggestions (given the fact that it needs to
accomodate a couple
of ten thousands of phones?)
Don't know - take a look at SEMS, Yate, Sippy, Asterisk, Freeswitch, etc.
--
Alex Balashov - Principal
Evariste Systems
Web :
http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671