[sr-dev] urgent mi_rpc errors

[Daniel-Constantin Mierla]

On 9/30/11 2:26 PM, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> Did a fix for the warnings and refactored the previous one. Try again
>> and let me know the results.
> now i didn't get any compilation errors and also sr started without
> problems.
>
> what were the big mi related changes?  what kind of bugs did they fixed?
the changes were not big by themselves, it was about when to call 
child_init and mi_child_init functions.

By design, and some time ago all was ok, there were created different 
processes handling SIP and handling MI (RPC), each calling an init 
function (if needed) after the process was forked, namely child_init 
from module exports structure by SIP workers and mi_child_init from MI 
commands export structure by MI workers.

But with the time, it got to the state when MI/RPC workers call route 
blocks (where are functions exported by modules to handle sip) and SIP 
workers have to handle RPC commands. Therfore in some cases, a process 
is both SIP and RPC/MI worker. The changes tried to detect when is such 
a case and initialize properly the children processes.

So, initially was added local_route introduced during openser/kamailio 
stand alone times, right now it is event_route[tm:local-request]. This 
route block is executed for local generated requests via tm. But such 
requests can be triggered by MI commands, thus handled by a MI worker 
(e.g., end dlg from dialog, pua_mi, t_uac* MI commands). An event route 
can have all functions available for REQUEST_ROUTE, but some of them do 
not work if module child_init was not called for that process. A good 
example is acc_db_request() -- it requires child_init to connect to 
database, on the other hand, acc has no mi command in order to have a 
mi_child_init function. If one sends a dlg end MI command and then want 
to account the generated BYEs to acc table, it failed in the past.

To work properly, each MI/RPC worker has to execute the child_init 
functions exported by modules

The other case is when SIP workers have to execute MI/RPC commands. It 
is the case when xmlrpc module is used, because this module works on the 
same transport layer as for SIP, the XMLRPC requests being handled by 
the same workers as SIP requests. For this, each SIP worker has to 
execute the mi_child_init exported by MI commands. This was partially 
fixed, by having mi_rpc module search to see if xmlrpc module was loaded 
and call mi_child_init functions in child_init.

The changes were:
- core keeps some flags about the type of the process, if it is going to 
handle SIP functions and/or RPC commands
- when tm is initialized, if event_route[tm:local-request] is defined, 
tells to core that RPC workers may execute SIP functions
- when xmlrpc is loaded, tells to the core that SIP workers may handle 
RPC commands
- based on this flags, mi_rpc module calls the mi_child_init() function 
in child_init() and the MI core API calls child_init() functions when 
initalizing MI workers

I haven't gotten to ctl module to see if it needs to do any fix for its 
extra workers, in the case event_route is going to be used from them.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda