[Kamailio-Users] re-invite mid call?

Alex Balashov abalashov at evaristesys.com
Fri Jan 1 18:37:08 CET 2010


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




More information about the sr-users mailing list