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.