[SR-Users] Playing with dlg_bridge()

Roberto Fichera kernel at tekno-soft.it
Thu Jul 7 16:01:00 CEST 2011


On 07/07/2011 02:51 PM, Henning Westerholt wrote:
> On Thursday 07 July 2011, Roberto Fichera wrote:
>>>> Do you know what does means the warning below?
>>>> [..]
>>>> 68.2.50 Jul  6 11:54:17 roberto /usr/sbin/kamailio[20457]: WARNING:
>>>> dialog [dlg_handlers.c:884]: unable to find dialog for NOTIFY with
>>>> route param '7d2.14447fc4' [727:1291273281]
>>> This means that the module can't find an existing (stored) dialog for the
>>> routed message in question, in this case a NOTIFY.
>> Does this depends by the fact of own the dlg_bridge() works? And in case,
>> how can I solve that problem?
> Hi Roberto,

Hi Henning,

> I'm not 100% sure, I'm not the expert for dlg_bridge.. To be more specific 
> (after discussion with Timo..) - the warning is emmited if the module can't 
> find the dialog with the ID added as a route parameter to the respective 
> message. One particiular reason is (if you don't store the dialogs in a 
> database) a simple kamailio restart, then all existing dialog information is 
> lost.

actually I've the following setup:

#!define DBURL "postgres://openser:openserrw@localhost/openser"

modparam("dialog", "dlg_flag", 2)
modparam("dialog", "bridge_controller", "sip:controller at 192.168.2.92")
modparam("dialog", "db_url", DBURL )

Actually, my thought is that problem is more strictly related to the dlg_bridge()
which might not track the bridged dialog.

Anyway, I'm playing with dlg_bridge() because I want to realize the logic so
that two peers, and if possible more, can talk together only if authorized.
The authorization might be a unique tag or transaction id, stored in a database,
and valid only for the give conversation {tag, caller, callee} once started, than
the tag become invalid and can't be used again.

I really like to have some suggestions about how to realize such logic,
so which might be the best way to approach such problem since I'm actually
a novice to Kamailio or in general with OpenSer logic. I'm actually more
confident with Asterisk logic.

> Best regards,
>
> Henning
>




More information about the sr-users mailing list