16 Apr
2014
16 Apr
'14
7:46 p.m.
Hi All,
I've started to play with MSILO module on kamailio v4.1.2, but it seems that all the
stored
messages aren't delivered to the give user even if, looking at the debug log, the
given messages
are found and queued for shipping. Another info I can add is that all the users are
connected in
TLS. The relevant conf is below. Doe anyone can suggest a working setup for TLS users?
Thanks in advance,
Roberto Fichera.
# ----- msilo params -----
modparam("msilo", "db_url", DBURL)
modparam("msilo", "from_address", "sip:$rU@test.net")
modparam("msilo", "contact_hdr", "Contact:
msilo@test.net:5060;msilo=yes\r\n")
modparam("msilo", "content_type_hdr", "Content-Type:
text/plain\r\n")
# Handle SIP registrations
route[REGISTRAR] {
if (is_method("REGISTER"))
{
if(isflagset(FLT_NATS))
{
setbflag(FLB_NATB);
# uncomment next line to do SIP NAT pinging
## setbflag(FLB_NATSIPPING);
}
# MSILO - dumping user's offline messages
if (m_dump())
{
xlog("MSILO: offline messages dumped - if they were for user
$fu\n");
}
else
{
xlog("MSILO: no offline messages dumped\n");
}
exit;
}
}
and in the route[LOCATION] I've this snippet
xlog( "Checking the destination user $rU exists\n");
if(avp_db_query("select username from subscriber where
username='$rU'"))
{
xlog("MESSAGE received $ru -> storing using MSILO user=$rU\n");
if(m_store("$ru"))
{
xlog("MSILO: offline message stored\n");
if (!t_reply("202", "Accepted"))
{
sl_reply_error();
}
}
else
{
xlog("MSILO: offline message NOT stored\n");
if (!t_reply("503", "Service Unavailable"))
{
sl_reply_error();
}
}
# if the downstream UA doesn't support MESSAGE requests
# go to failure_route[1]
t_on_failure("1");
exit;
}
else
{
# The destination recipiend doen't exist
xlog( "Unable to store message for $ru because the user doesn't
exist" );
if (!t_reply("404", "Not Found"))
{
sl_reply_error();
}
exit;
}
}
16 Apr
16 Apr
7:53 p.m.
Hello,
most likely the messages are looped back, be sure you allow requests
from 'myself' without authentication.
You can watch loopback interface with ngrep to see if the messages are
sent out.
Cheers,
Daniel
On 16/04/14 18:46, Roberto Fichera wrote:
Hi All,
I've started to play with MSILO module on kamailio v4.1.2, but it seems that all the
stored
messages aren't delivered to the give user even if, looking at the debug log, the
given messages
are found and queued for shipping. Another info I can add is that all the users are
connected in
TLS. The relevant conf is below. Doe anyone can suggest a working setup for TLS users?
Thanks in advance,
Roberto Fichera.
# ----- msilo params -----
modparam("msilo", "db_url", DBURL)
modparam("msilo", "from_address", "sip:$rU@test.net")
modparam("msilo", "contact_hdr", "Contact:
msilo@test.net:5060;msilo=yes\r\n")
modparam("msilo", "content_type_hdr", "Content-Type:
text/plain\r\n")
# Handle SIP registrations
route[REGISTRAR] {
if (is_method("REGISTER"))
{
if(isflagset(FLT_NATS))
{
setbflag(FLB_NATB);
# uncomment next line to do SIP NAT pinging
## setbflag(FLB_NATSIPPING);
}
# MSILO - dumping user's offline messages
if (m_dump())
{
xlog("MSILO: offline messages dumped - if they were for user
$fu\n");
}
else
{
xlog("MSILO: no offline messages dumped\n");
}
exit;
}
}
and in the route[LOCATION] I've this snippet
xlog( "Checking the destination user $rU exists\n");
if(avp_db_query("select username from subscriber where
username='$rU'"))
{
xlog("MESSAGE received $ru -> storing using MSILO user=$rU\n");
if(m_store("$ru"))
{
xlog("MSILO: offline message stored\n");
if (!t_reply("202", "Accepted"))
{
sl_reply_error();
}
}
else
{
xlog("MSILO: offline message NOT stored\n");
if (!t_reply("503", "Service Unavailable"))
{
sl_reply_error();
}
}
# if the downstream UA doesn't support MESSAGE requests
# go to failure_route[1]
t_on_failure("1");
exit;
}
else
{
# The destination recipiend doen't exist
xlog( "Unable to store message for $ru because the user doesn't
exist" );
if (!t_reply("404", "Not Found"))
{
sl_reply_error();
}
exit;
}
}
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
8:15 p.m.
On 04/16/2014 06:53 PM, Daniel-Constantin Mierla wrote:
Hello,
Ciao Daniel,
most likely the messages are looped back, be sure you allow requests from
'myself' without authentication.
You can watch loopback interface with ngrep to see if the messages are sent out.
Yep! Allowing requests from myself solved the problem! Thanks!
Another thing regarding MSILO, I would like to preserve some custom header fields
for both instant message and notification. How can I do it?
Cheers,
Roberto Fichera.
Cheers,
Daniel
On 16/04/14 18:46, Roberto Fichera wrote:
Hi All,
I've started to play with MSILO module on kamailio v4.1.2, but it seems that all the
stored
messages aren't delivered to the give user even if, looking at the debug log, the
given messages
are found and queued for shipping. Another info I can add is that all the users are
connected in
TLS. The relevant conf is below. Doe anyone can suggest a working setup for TLS users?
Thanks in advance,
Roberto Fichera.
# ----- msilo params -----
modparam("msilo", "db_url", DBURL)
modparam("msilo", "from_address", "sip:$rU@test.net")
modparam("msilo", "contact_hdr", "Contact:
msilo@test.net:5060;msilo=yes\r\n")
modparam("msilo", "content_type_hdr", "Content-Type:
text/plain\r\n")
# Handle SIP registrations
route[REGISTRAR] {
if (is_method("REGISTER"))
{
if(isflagset(FLT_NATS))
{
setbflag(FLB_NATB);
# uncomment next line to do SIP NAT pinging
## setbflag(FLB_NATSIPPING);
}
# MSILO - dumping user's offline messages
if (m_dump())
{
xlog("MSILO: offline messages dumped - if they were for user
$fu\n");
}
else
{
xlog("MSILO: no offline messages dumped\n");
}
exit;
}
}
and in the route[LOCATION] I've this snippet
xlog( "Checking the destination user $rU exists\n");
if(avp_db_query("select username from subscriber where
username='$rU'"))
{
xlog("MESSAGE received $ru -> storing using MSILO user=$rU\n");
if(m_store("$ru"))
{
xlog("MSILO: offline message stored\n");
if (!t_reply("202", "Accepted"))
{
sl_reply_error();
}
}
else
{
xlog("MSILO: offline message NOT stored\n");
if (!t_reply("503", "Service Unavailable"))
{
sl_reply_error();
}
}
# if the downstream UA doesn't support MESSAGE requests
# go to failure_route[1]
t_on_failure("1");
exit;
}
else
{
# The destination recipiend doen't exist
xlog( "Unable to store message for $ru because the user doesn't
exist" );
if (!t_reply("404", "Not Found"))
{
sl_reply_error();
}
exit;
}
}
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
17 Apr
17 Apr
11:36 a.m.
On 04/16/2014 07:15 PM, Roberto Fichera wrote:
Hi All,
On 04/16/2014 06:53 PM, Daniel-Constantin Mierla
wrote:
I was able to solve this issue too, pretty straight I mean, there is the extra_hdrs_avp
param
which did the trick. BTW, is there a way to send back the notification to the sender that
the message has been sent correctly via m_dump(), so to get a 200 about the given
m_dump()ed message?
Thanks in advance,
Roberto Fichera.
Hello,
Ciao Daniel,
most likely the messages are looped back, be sure
you allow requests from 'myself' without authentication.
You can watch loopback interface with ngrep to see if the messages are sent out.
Yep! Allowing requests from myself solved the problem! Thanks!
Another thing regarding MSILO, I would like to preserve some custom header fields
for both instant message and notification. How can I do it?
Cheers,
Roberto Fichera.
Cheers,
Daniel
On 16/04/14 18:46, Roberto Fichera wrote:
> Hi All,
>
> I've started to play with MSILO module on kamailio v4.1.2, but it seems that all
the stored
> messages aren't delivered to the give user even if, looking at the debug log, the
given messages
> are found and queued for shipping. Another info I can add is that all the users are
connected in
> TLS. The relevant conf is below. Doe anyone can suggest a working setup for TLS
users?
>
> Thanks in advance,
> Roberto Fichera.
>
> # ----- msilo params -----
> modparam("msilo", "db_url", DBURL)
> modparam("msilo", "from_address", "sip:$rU@test.net")
> modparam("msilo", "contact_hdr", "Contact:
msilo@test.net:5060;msilo=yes\r\n")
> modparam("msilo", "content_type_hdr", "Content-Type:
text/plain\r\n")
>
> # Handle SIP registrations
> route[REGISTRAR] {
> if (is_method("REGISTER"))
> {
> if(isflagset(FLT_NATS))
> {
> setbflag(FLB_NATB);
> # uncomment next line to do SIP NAT pinging
> ## setbflag(FLB_NATSIPPING);
> }
>
> # MSILO - dumping user's offline messages
> if (m_dump())
> {
> xlog("MSILO: offline messages dumped - if they were for user
$fu\n");
> }
> else
> {
> xlog("MSILO: no offline messages dumped\n");
> }
>
> exit;
> }
> }
>
> and in the route[LOCATION] I've this snippet
>
> xlog( "Checking the destination user $rU exists\n");
> if(avp_db_query("select username from subscriber where
username='$rU'"))
> {
> xlog("MESSAGE received $ru -> storing using MSILO
user=$rU\n");
> if(m_store("$ru"))
> {
> xlog("MSILO: offline message stored\n");
> if (!t_reply("202", "Accepted"))
> {
> sl_reply_error();
> }
> }
> else
> {
> xlog("MSILO: offline message NOT stored\n");
> if (!t_reply("503", "Service Unavailable"))
> {
> sl_reply_error();
> }
> }
> # if the downstream UA doesn't support MESSAGE requests
> # go to failure_route[1]
> t_on_failure("1");
> exit;
> }
> else
> {
> # The destination recipiend doen't exist
> xlog( "Unable to store message for $ru because the user doesn't
exist" );
> if (!t_reply("404", "Not Found"))
> {
> sl_reply_error();
> }
> exit;
> }
> }
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
6:04 p.m.
On 04/17/2014 10:36 AM, Roberto Fichera wrote:
Hi All,
On 04/16/2014 07:15 PM, Roberto Fichera wrote:
Hi All,
I think that this can be solved in a different way, the idea is to add an event_route for
the msilo
module so that we get notified for each m_dump()ed message about the given IM status and
then handle it in the cfg file. So, looking at the code within m_tm_callback() it seems
that it's
right place where to add such feature. Since I'm not a kamailio developer but I've
quite long
time experience in C coding, does anyone can show/point me to some example about
how to do that?
Thanks in advance,
Roberto Fichera.
On 04/16/2014 06:53 PM, Daniel-Constantin Mierla
wrote:
I was able to solve
this issue too, pretty straight I mean, there is the extra_hdrs_avp param
which did the trick. BTW, is there a way to send back the notification to the sender
that
the message has been sent correctly via m_dump(), so to get a 200 about the given
m_dump()ed message?
Hello,
Ciao Daniel,
most likely the messages are looped back, be sure
you allow requests from 'myself' without authentication.
You can watch loopback interface with ngrep to see if the messages are sent out.
Yep! Allowing requests from myself solved the problem! Thanks!
Another thing regarding MSILO, I would like to preserve some custom header fields
for both instant message and notification. How can I do it? 
20 May
20 May
10:15 p.m.
Hi Roberto,
Did you ever figure out how to do it?
I'd be interested too.
Cheers,
Peter
On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera <kernel(a)tekno-soft.it>wrote;wrote:
On 04/17/2014 10:36 AM, Roberto Fichera wrote:
Hi All,
extra_hdrs_avp param
On 04/16/2014 07:15 PM, Roberto Fichera wrote:
Hi All,
> On 04/16/2014 06:53 PM, Daniel-Constantin Mierla wrote:
>> Hello,
> Ciao Daniel,
>
>> most likely the messages are looped back, be sure you allow requests
from
'myself' without authentication.
>>
>> You can watch loopback interface with ngrep to see if the messages are
sent out.
> Yep! Allowing requests from myself solved the
problem! Thanks!
>
> Another thing regarding MSILO, I would like to preserve some custom
header
fields
for both
instant message and notification. How can I do it?
I was able to solve this issue
too, pretty straight I mean, there is the which did the trick. BTW, is there a way to send
back the notification
to the sender that
the message has been sent correctly via m_dump(),
so to get a 200 about
the given
m_dump()ed message?
I think that this can be solved in a different way, the idea is to add an
event_route for the msilo
module so that we get notified for each m_dump()ed message about the given
IM status and
then handle it in the cfg file. So, looking at the code within
m_tm_callback() it seems that it's
right place where to add such feature. Since I'm not a kamailio developer
but I've quite long
time experience in C coding, does anyone can show/point me to some example
about
how to do that?
Thanks in advance,
Roberto Fichera.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
21 May
21 May
10:08 a.m.
On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
Hi Roberto,
Hi Peter,
Did you ever figure out how to do it?
I'd be interested too.
Not yet! I tried other ways, barely workarounds, but I guess I'll have to go into
this
quite soon because it is the straight way to go. The main problem is the lack of
my knowledge of kamailio API so I'll have to study a bit some code in order to
understand
how to use it.
BTW the idea is to trigger an event route were I'd like to set all the info regarding
the dispatched message including the result of the delivering. I don't know if is
possible
but the best would be to set all the pseudo-variables so that such event route will be
in the right context of the given MSILO message.
So, any advice regarding the API would definitively help and put me in the right
direction.
Cheers,
Roberto Fichera.
Cheers,
Peter
On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera <kernel(a)tekno-soft.it
<mailto:kernel@tekno-soft.it>> wrote:
On 04/17/2014 10:36 AM, Roberto Fichera wrote:
Hi All,
On 04/16/2014 07:15 PM, Roberto Fichera wrote:
Hi All,
I think that this can be solved in a different way, the idea is to add an event_route
for the msilo
module so that we get notified for each m_dump()ed message about the given IM status
and
then handle it in the cfg file. So, looking at the code within m_tm_callback() it
seems that it's
right place where to add such feature. Since I'm not a kamailio developer but
I've quite long
time experience in C coding, does anyone can show/point me to some example about
how to do that?
Thanks in advance,
Roberto Fichera.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On 04/16/2014 06:53 PM, Daniel-Constantin Mierla
wrote:
I was able to solve
this issue too, pretty straight I mean, there is the extra_hdrs_avp param
which did the trick. BTW, is there a way to send back the notification to the sender
that
the message has been sent correctly via m_dump(), so to get a 200 about the given
m_dump()ed message?
Hello,
Ciao Daniel,
most likely the messages are looped back, be sure
you allow requests from 'myself' without authentication.
You can watch loopback interface with ngrep to see if the messages are sent out.
Yep! Allowing requests from myself solved the problem! Thanks!
Another thing regarding MSILO, I would like to preserve some custom header fields
for both instant message and notification. How can I do it?
7:37 p.m.
On 05/21/2014 09:08 AM, Roberto Fichera wrote:
Hi There,
On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
Actually I've started to play with the above idea, so below you will find my current
implementation
which seems executed because I see the LM_DBG() log but the code within the event route
but
the corresponding script code does not.
Any help?
Cheers,
Roberto Fichera.
event_route [msilo:on-delivered] {
xlog("L_INFO", "MSILO event on-delivered <$fu> to
<$ru>\n");
}
diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
index 903b3cf..742c48d 100644
--- a/modules/msilo/msilo.c
+++ b/modules/msilo/msilo.c
@@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
return 0;
}
+/* where to go for the local request route ("msilo:on-delivered") */
+int msilo_event_on_delivered=-1; /* default disabled */
+
/**
* init module function
*/
@@ -480,6 +483,11 @@ static int mod_init(void)
if(ms_outbound_proxy.s!=NULL)
ms_outbound_proxy.len = strlen(ms_outbound_proxy.s);
+ /* check if the on-delivered route event exists or not */
+ msilo_event_on_delivered=route_lookup(&event_rt,
"msilo:on-delivered");
+ if (msilo_event_on_delivered>=0 &&
event_rt.rlist[msilo_event_on_delivered]==0)
+ msilo_event_on_delivered=-1; /* disable */
+
return 0;
}
@@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t, int type, struct tmcb_params
*ps)
LM_DBG("message <%d> was sent successfully\n",
*((int*)ps->param));
msg_list_set_flag(ml, *((int*)ps->param), MS_MSG_DONE);
+ /* execute the msilo:on-delivered event route */
+ if(unlikely(msilo_event_on_delivered>=0))
+ {
+ int sflag_bk;
+ int backup_route_type;
+ struct run_act_ctx ctx;
+
+ LM_DBG("executing event_route[msilo:on-delivered] (%d)\n",
msilo_event_on_delivered);
+
+ sflag_bk = getsflags();
+ backup_route_type = get_route_type();
+
+ set_route_type(EVENT_ROUTE);
+ init_run_actions_ctx(&ctx);
+ run_top_route(event_rt.rlist[msilo_event_on_delivered], ps->req,
&ctx);
+
+ set_route_type(backup_route_type);
+ setsflagsval(sflag_bk);
+ }
+
done:
return;
}
Hi Roberto,
Hi Peter,
Did you ever figure out how to do it?
I'd be interested too.
Not yet! I tried other ways, barely workarounds, but I guess I'll have to go into
this
quite soon because it is the straight way to go. The main problem is the lack of
my knowledge of kamailio API so I'll have to study a bit some code in order to
understand
how to use it.
BTW the idea is to trigger an event route were I'd like to set all the info
regarding
the dispatched message including the result of the delivering. I don't know if is
possible
but the best would be to set all the pseudo-variables so that such event route will be
in the right context of the given MSILO message.
So, any advice regarding the API would definitively help and put me in the right
direction.
Cheers,
Roberto Fichera.
Cheers,
Peter
On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera <kernel(a)tekno-soft.it
<mailto:kernel@tekno-soft.it>> wrote:
On 04/17/2014 10:36 AM, Roberto Fichera wrote:
Hi All,
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On 04/16/2014 07:15 PM, Roberto Fichera wrote:
Hi All,
I think that this can be solved in a different way, the idea is to add an event_route
for the msilo
module so that we get notified for each m_dump()ed message about the given IM status
and
then handle it in the cfg file. So, looking at the code within m_tm_callback() it
seems that it's
right place where to add such feature. Since I'm not a kamailio developer but
I've quite long
time experience in C coding, does anyone can show/point me to some example about
how to do that?
Thanks in advance,
Roberto Fichera.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On 04/16/2014 06:53 PM, Daniel-Constantin Mierla
wrote:
> Hello,
Ciao Daniel,
> most likely the messages are looped back, be sure you allow requests from
'myself' without authentication.
>
> You can watch loopback interface with ngrep to see if the messages are sent out.
Yep! Allowing requests from myself solved the problem! Thanks!
Another thing regarding MSILO, I would like to preserve some custom header fields
for both instant message and notification. How can I do it?
I was able to solve
this issue too, pretty straight I mean, there is the extra_hdrs_avp param
which did the trick. BTW, is there a way to send back the notification to the sender
that
the message has been sent correctly via m_dump(), so to get a 200 about the given
m_dump()ed message?
11:27 p.m.
Hi Roberto,
Thanks for your feedback. Unfortuntately I cannot really help you since I'm
still learning the ropes in Kamailio.
I'm sure there are others on this list much more qualified to help.
Hopefully someone will help out and point you in the right direction.
Best,
Peter
On Wed, May 21, 2014 at 5:37 PM, Roberto Fichera <kernel(a)tekno-soft.it>wrote;wrote:
On 05/21/2014 09:08 AM, Roberto Fichera wrote:
Hi There,
On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
Hi Roberto,
Hi Peter,
Did you ever figure out how to do it?
I'd be interested too.
Not yet! I tried other ways, barely workarounds, but I guess I'll have to
go into this
quite soon because it is the straight way to go. The main problem is the
lack of
my knowledge of kamailio API so I'll have to study a bit some code in
order to understand
how to use it.
BTW the idea is to trigger an event route were I'd like to set all the
info regarding
the dispatched message including the result of the delivering. I don't
know if is possible
but the best would be to set all the pseudo-variables so that such event
route will be
in the right context of the given MSILO message.
So, any advice regarding the API would definitively help and put me in the
right direction.
Actually I've started to play with the above idea, so below you will find
my current implementation
which seems executed because I see the LM_DBG() log but the code within
the event route but
the corresponding script code does not.
Any help?
Cheers,
Roberto Fichera.
event_route [msilo:on-delivered] {
xlog("L_INFO", "MSILO event on-delivered <$fu> to
<$ru>\n");
}
diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
index 903b3cf..742c48d 100644
--- a/modules/msilo/msilo.c
+++ b/modules/msilo/msilo.c
@@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
return 0;
}
+/* where to go for the local request route ("msilo:on-delivered") */
+int msilo_event_on_delivered=-1; /* default disabled */
+
/**
* init module function
*/
@@ -480,6 +483,11 @@ static int mod_init(void)
if(ms_outbound_proxy.s!=NULL)
ms_outbound_proxy.len = strlen(ms_outbound_proxy.s);
+ /* check if the on-delivered route event exists or not */
+ msilo_event_on_delivered=route_lookup(&event_rt,
"msilo:on-delivered");
+ if (msilo_event_on_delivered>=0 &&
event_rt.rlist[msilo_event_on_delivered]==0)
+ msilo_event_on_delivered=-1; /* disable */
+
return 0;
}
@@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t, int type,
struct tmcb_params *ps)
LM_DBG("message <%d> was sent successfully\n",
*((int*)ps->param));
msg_list_set_flag(ml, *((int*)ps->param), MS_MSG_DONE);
+ /* execute the msilo:on-delivered event route */
+ if(unlikely(msilo_event_on_delivered>=0))
+ {
+ int sflag_bk;
+ int backup_route_type;
+ struct run_act_ctx ctx;
+
+ LM_DBG("executing event_route[msilo:on-delivered]
(%d)\n", msilo_event_on_delivered);
+
+ sflag_bk = getsflags();
+ backup_route_type = get_route_type();
+
+ set_route_type(EVENT_ROUTE);
+ init_run_actions_ctx(&ctx);
+ run_top_route(event_rt.rlist[msilo_event_on_delivered],
ps->req, &ctx);
+
+ set_route_type(backup_route_type);
+ setsflagsval(sflag_bk);
+ }
+
done:
return;
}
Cheers,
Roberto Fichera.
Cheers,
Peter
On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera <kernel(a)tekno-soft.it>wrote;wrote:
On 04/17/2014 10:36 AM, Roberto Fichera wrote:
Hi All,
the extra_hdrs_avp param
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 04/16/2014 07:15 PM, Roberto Fichera wrote:
Hi All,
> On 04/16/2014 06:53 PM, Daniel-Constantin Mierla wrote:
>> Hello,
> Ciao Daniel,
>
>> most likely the messages are looped back, be sure you allow requests
from
'myself' without authentication.
>>
>> You can watch loopback interface with ngrep to see if the messages
are
sent out.
> Yep! Allowing requests from myself solved the
problem! Thanks!
>
> Another thing regarding MSILO, I would like to preserve some custom
header
fields
for both
instant message and notification. How can I do it?
I was able to solve this issue
too, pretty straight I mean, there is which did the trick. BTW, is there a way to send
back the notification
to the sender that
the message has been sent correctly via m_dump(),
so to get a 200 about
the given
m_dump()ed message?
I think that this can be solved in a different way, the idea is to add
an event_route for the msilo
module so that we get notified for each m_dump()ed message about the
given IM status and
then handle it in the cfg file. So, looking at the code within
m_tm_callback() it seems that it's
right place where to add such feature. Since I'm not a kamailio developer
but I've quite long
time experience in C coding, does anyone can show/point me to some
example about
how to do that?
Thanks in advance,
Roberto Fichera.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
22 May
22 May
12:15 a.m.
Hello,
can you send the log messages printed with debug=3?
Cheers,
Daniel
On 21/05/14 18:37, Roberto Fichera wrote:
On 05/21/2014 09:08 AM, Roberto Fichera wrote:
Hi There,
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
Actually I've started to play with the above idea, so below you will
find my current implementation
which seems executed because I see the LM_DBG() log but the code
within the event route but
the corresponding script code does not.
Any help?
Cheers,
Roberto Fichera.
event_route [msilo:on-delivered] {
xlog("L_INFO", "MSILO event on-delivered <$fu> to
<$ru>\n");
}
diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
index 903b3cf..742c48d 100644
--- a/modules/msilo/msilo.c
+++ b/modules/msilo/msilo.c
@@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
return 0;
}
+/* where to go for the local request route ("msilo:on-delivered") */
+int msilo_event_on_delivered=-1; /* default disabled */
+
/**
* init module function
*/
@@ -480,6 +483,11 @@ static int mod_init(void)
if(ms_outbound_proxy.s!=NULL)
ms_outbound_proxy.len = strlen(ms_outbound_proxy.s);
+ /* check if the on-delivered route event exists or not */
+ msilo_event_on_delivered=route_lookup(&event_rt,
"msilo:on-delivered");
+ if (msilo_event_on_delivered>=0 &&
event_rt.rlist[msilo_event_on_delivered]==0)
+ msilo_event_on_delivered=-1; /* disable */
+
return 0;
}
@@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t, int type,
struct tmcb_params *ps)
LM_DBG("message <%d> was sent successfully\n",
*((int*)ps->param));
msg_list_set_flag(ml, *((int*)ps->param), MS_MSG_DONE);
+ /* execute the msilo:on-delivered event route */
+ if(unlikely(msilo_event_on_delivered>=0))
+ {
+ int sflag_bk;
+ int backup_route_type;
+ struct run_act_ctx ctx;
+
+ LM_DBG("executing event_route[msilo:on-delivered]
(%d)\n", msilo_event_on_delivered);
+
+ sflag_bk = getsflags();
+ backup_route_type = get_route_type();
+
+ set_route_type(EVENT_ROUTE);
+ init_run_actions_ctx(&ctx);
+ run_top_route(event_rt.rlist[msilo_event_on_delivered], ps->req, &ctx);
+
+ set_route_type(backup_route_type);
+ setsflagsval(sflag_bk);
+ }
+
done:
return;
}
Hi Roberto,
Hi Peter,
Did you ever figure out how to do it?
I'd be interested too.
Not yet! I tried other ways, barely workarounds, but I guess I'll
have to go into this
quite soon because it is the straight way to go. The main problem is
the lack of
my knowledge of kamailio API so I'll have to study a bit some code in
order to understand
how to use it.
BTW the idea is to trigger an event route were I'd like to set all
the info regarding
the dispatched message including the result of the delivering. I
don't know if is possible
but the best would be to set all the pseudo-variables so that such
event route will be
in the right context of the given MSILO message.
So, any advice regarding the API would definitively help and put me
in the right direction.
Cheers,
Roberto Fichera.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Cheers,
Peter
On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera
<kernel(a)tekno-soft.it <mailto:kernel@tekno-soft.it>> wrote:
On 04/17/2014 10:36 AM, Roberto Fichera wrote:
Hi All,
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On 04/16/2014 07:15 PM, Roberto Fichera wrote:
Hi All,
> On 04/16/2014 06:53 PM, Daniel-Constantin Mierla wrote:
>> Hello,
> Ciao Daniel,
>
>> most likely the messages are looped back, be sure you allow
requests
from 'myself' without authentication.
>>
>> You can watch loopback interface with ngrep to see if the
messages are
sent out.
> Yep! Allowing requests from myself solved the
problem! Thanks!
>
> Another thing regarding MSILO, I would like to preserve some
custom header
fields
> for both instant message and notification.
How can I do it?
I was able to solve this issue too, pretty straight I mean,
there is the
extra_hdrs_avp param
which did the trick. BTW, is there a way to send
back the
notification to the sender that
the message has been sent correctly via m_dump(),
so to get a
200 about the given
m_dump()ed message?
I think that this can be solved in a different way, the idea is
to add an event_route for the msilo
module so that we get notified for each m_dump()ed message about
the given IM status and
then handle it in the cfg file. So, looking at the code within
m_tm_callback() it seems that it's
right place where to add such feature. Since I'm not a kamailio
developer but I've quite long
time experience in C coding, does anyone can show/point me to
some example about
how to do that?
Thanks in advance,
Roberto Fichera.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
10:08 a.m.
On 05/21/2014 11:15 PM, Daniel-Constantin Mierla wrote:
Hello,
Ciao,
can you send the log messages printed with debug=3?
Yes! Sure! Here it is:
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG: <core>
[receive.c:296]: receive_msg():
receive_msg: cleaning up
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:633]: parse_msg(): SIP
Reply (status):
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:635]: parse_msg():
version: <SIP/2.0>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:637]: parse_msg():
status: <202>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:639]: parse_msg():
reason: <Accepted>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_via.c:1284]:
parse_via_param(): Found param type 232, <branch> =
<z9hG4bK016e.a6c662d4000000000000000....0>; state=6
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_via.c:1284]:
parse_via_param(): Found param type 235, <rport> = <1169>; state=6
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_via.c:1284]:
parse_via_param(): Found param type 234, <received> = <xx.xx.xx.xx>; state=16
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_via.c:2672]: parse_via(): end
of header reached, state=5
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:513]: parse_headers():
parse_headers: Via found, flags=2
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:515]: parse_headers():
parse_headers: this is the first via
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[receive.c:152]: receive_msg(): After
parse_msg...
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:1072]: t_check_msg(): DEBUG:
t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_addr_spec.c:176]:
parse_to_param(): DEBUG: add_param: tag=74b38630e6be28bab2ebe17319971f33-c57e
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_addr_spec.c:893]:
parse_addr_spec(): end of header reached, state=29
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:190]: get_hdr_field():
DEBUG: get_hdr_field: <To> [88]; uri=[sip:test1@test.com]
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:192]: get_hdr_field():
DEBUG: to body [<sip:test1@test.com>]
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:170]: get_hdr_field():
get_hdr_field: cseq <CSeq>: <10> <MESSAGE>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm [t_lookup.c:949]:
t_reply_matching(): DEBUG:
t_reply_matching: hash 58896 label 0 branch 0
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:1004]: t_reply_matching(): DEBUG:
t_reply_matching: reply matched (T=0x7f21ba974408)!
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:1141]: t_check_msg(): DEBUG:
t_check_msg: msg id=1 global id=1 T end=0x7f21ba974408
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm [t_reply.c:2206]:
reply_received(): DEBUG:
reply_received: org. status uas=0, uac[0]=0 local=2 is_invite=0)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm [t_reply.c:1304]:
t_should_relay_response():
->>>>>>>>> T_code=0, new_code=202
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm [t_reply.c:2086]:
local_reply(): DEBUG:
local_reply: branch=0, save=0, winner=0
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm [t_reply.c:2123]:
local_reply(): DEBUG: local
transaction completed
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm [t_hooks.c:288]:
run_trans_callbacks_internal(): DBG: trans=0x7f21ba974408, callback type 1024, id 0
entered
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[msilo.c:1327]: m_tm_callback(): completed
with status 202 [mid: 139782841221704/4]
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[msilo.c:1340]: m_tm_callback(): message <4>
was sent successfully
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[ms_msg_list.c:236]: msg_list_set_flag():
mid:4 fl:4
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[msilo.c:1350]: m_tm_callback(): executing
event_route[msilo:on-delivered] (2)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm [t_reply.c:1663]:
cleanup_uac_timers(): DEBUG:
cleanup_uac_timers: RETR/FR timers reset
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[xavp.c:448]: xavp_destroy_list():
destroying xavp list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[receive.c:296]: receive_msg():
receive_msg: cleaning up
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike [timer.c:77]:
check_and_split_timer():
splitting 0x7f21ba98dab0(0x7f21ba7b15f8,0x7f21ba7b15f8)node=0x7f21ba98daa0
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike [timer.c:102]:
check_and_split_timer(): succ.
to split (h=0x7f21ba7b15f8)(p=0x7f21ba7b15f8,n=0x7f21ba7b15f8)
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[pike_funcs.c:234]: clean_routine(): clean
node 0x7f21ba98daa0 (kids=(nil); hits=[0,0];leaf=[0,0])
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[pike_funcs.c:265]: clean_routine(): rmv node
0x7f21ba98daa0[192]
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[ip_tree.c:364]: remove_node(): destroying
node 0x7f21ba98daa0
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG: <core>
[io_wait.h:617]: io_watch_del(): DBG:
io_watch_del (0x8eb2e0, 9, -1, 0x10) fd_no=2 called
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG: <core>
[tcp_read.c:1437]: release_tcpconn():
releasing con 0x7f21ba9420c0, state 1, fd=9, id=2
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG: <core>
[tcp_read.c:1438]: release_tcpconn():
extra_data 0x7f21ba941028
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG: <core>
[tcp_main.c:3385]: handle_tcp_child():
handle_tcp_child: reader response= 7f21ba9420c0, 1 from 2
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG: <core>
[io_wait.h:390]: io_watch_add(): DBG:
io_watch_add(0x893040, 28, 2, 0x7f21ba9420c0), fd_no=20
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG: <core>
[tcp_main.c:3515]: handle_tcp_child():
handle_tcp_child: CONN_RELEASE 0x7f21ba9420c0 refcnt= 1
Cheers,
Roberto Fichera.
>
> Cheers,
> Daniel
>
> On 21/05/14 18:37, Roberto Fichera wrote:
>> On 05/21/2014 09:08 AM, Roberto Fichera wrote:
>>
>> Hi There,
>>
>>> On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
>>>> Hi Roberto,
>>>
>>> Hi Peter,
>>>
>>>> Did you ever figure out how to do it?
>>>> I'd be interested too.
>>>
>>> Not yet! I tried other ways, barely workarounds, but I guess I'll have to
go into this
>>> quite soon because it is the straight way to go. The main problem is the lack
of
>>> my knowledge of kamailio API so I'll have to study a bit some code in
order to understand
>>> how to use it.
>>>
>>> BTW the idea is to trigger an event route were I'd like to set all the
info regarding
>>> the dispatched message including the result of the delivering. I don't
know if is possible
>>> but the best would be to set all the pseudo-variables so that such event
route will be
>>> in the right context of the given MSILO message.
>>>
>>> So, any advice regarding the API would definitively help and put me in the
right direction.
>>
>> Actually I've started to play with the above idea, so below you will find my
current implementation
>> which seems executed because I see the LM_DBG() log but the code within the event
route but
>> the corresponding script code does not.
>>
>> Any help?
>>
>> Cheers,
>> Roberto Fichera.
>>
>>
>> event_route [msilo:on-delivered] {
>> xlog("L_INFO", "MSILO event on-delivered <$fu> to
<$ru>\n");
>> }
>>
>>
>> diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
>> index 903b3cf..742c48d 100644
>> --- a/modules/msilo/msilo.c
>> +++ b/modules/msilo/msilo.c
>> @@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
>> return 0;
>> }
>>
>> +/* where to go for the local request route ("msilo:on-delivered") */
>> +int msilo_event_on_delivered=-1; /* default disabled */
>> +
>> /**
>> * init module function
>> */
>> @@ -480,6 +483,11 @@ static int mod_init(void)
>> if(ms_outbound_proxy.s!=NULL)
>> ms_outbound_proxy.len = strlen(ms_outbound_proxy.s);
>>
>> + /* check if the on-delivered route event exists or not */
>> + msilo_event_on_delivered=route_lookup(&event_rt,
"msilo:on-delivered");
>> + if (msilo_event_on_delivered>=0 &&
event_rt.rlist[msilo_event_on_delivered]==0)
>> + msilo_event_on_delivered=-1; /* disable */
>> +
>> return 0;
>> }
>>
>> @@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t, int type, struct
tmcb_params *ps)
>> LM_DBG("message <%d> was sent successfully\n",
*((int*)ps->param));
>> msg_list_set_flag(ml, *((int*)ps->param), MS_MSG_DONE);
>>
>> + /* execute the msilo:on-delivered event route */
>> + if(unlikely(msilo_event_on_delivered>=0))
>> + {
>> + int sflag_bk;
>> + int backup_route_type;
>> + struct run_act_ctx ctx;
>> +
>> + LM_DBG("executing event_route[msilo:on-delivered]
(%d)\n", msilo_event_on_delivered);
>> +
>> + sflag_bk = getsflags();
>> + backup_route_type = get_route_type();
>> +
>> + set_route_type(EVENT_ROUTE);
>> + init_run_actions_ctx(&ctx);
>> + run_top_route(event_rt.rlist[msilo_event_on_delivered],
ps->req, &ctx);
>> +
>> + set_route_type(backup_route_type);
>> + setsflagsval(sflag_bk);
>> + }
>> +
>> done:
>> return;
>> }
>>
>>
>>>
>>> Cheers,
>>> Roberto Fichera.
>>>
>>>>
>>>> Cheers,
>>>> Peter
>>>>
>>>>
>>>> On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera <kernel(a)tekno-soft.it
<mailto:kernel@tekno-soft.it>> wrote:
>>>>
>>>> On 04/17/2014 10:36 AM, Roberto Fichera wrote:
>>>>
>>>> Hi All,
>>>>
>>>> > On 04/16/2014 07:15 PM, Roberto Fichera wrote:
>>>> >
>>>> > Hi All,
>>>> >
>>>> >> On 04/16/2014 06:53 PM, Daniel-Constantin Mierla wrote:
>>>> >> Hello,
>>>> >> Ciao Daniel,
>>>> >>
>>>> >>> most likely the messages are looped back, be sure you
allow requests from 'myself' without authentication.
>>>> >>>
>>>> >>> You can watch loopback interface with ngrep to see if
the messages are sent out.
>>>> >> Yep! Allowing requests from myself solved the problem!
Thanks!
>>>> >>
>>>> >> Another thing regarding MSILO, I would like to preserve some
custom header fields
>>>> >> for both instant message and notification. How can I do it?
>>>> > I was able to solve this issue too, pretty straight I mean,
there is the extra_hdrs_avp param
>>>> > which did the trick. BTW, is there a way to send back the
notification to the sender that
>>>> > the message has been sent correctly via m_dump(), so to get a
200 about the given
>>>> > m_dump()ed message?
>>>> >
>>>>
>>>> I think that this can be solved in a different way, the idea is to
add an event_route for the msilo
>>>> module so that we get notified for each m_dump()ed message about the
given IM status and
>>>> then handle it in the cfg file. So, looking at the code within
m_tm_callback() it seems that it's
>>>> right place where to add such feature. Since I'm not a kamailio
developer but I've quite long
>>>> time experience in C coding, does anyone can show/point me to some
example about
>>>> how to do that?
>>>>
>>>> Thanks in advance,
>>>> Roberto Fichera.
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
>>>> sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users(a)lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
26 May
26 May
12:40 p.m.
On 05/22/2014 09:08 AM, Roberto Fichera wrote:
On 05/21/2014 11:15 PM, Daniel-Constantin Mierla
wrote:
> Hello,
Ciao Daniel,
have you had time to look at the problem below?
Cheers,
Roberto Fichera.
Ciao,
can you send the log messages printed with
debug=3?
Yes! Sure! Here it is:
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG: <core>
[receive.c:296]: receive_msg():
receive_msg: cleaning up
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:633]: parse_msg():
SIP Reply (status):
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:635]: parse_msg():
version: <SIP/2.0>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:637]: parse_msg():
status: <202>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:639]: parse_msg():
reason: <Accepted>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_via.c:1284]:
parse_via_param(): Found param type 232, <branch> =
<z9hG4bK016e.a6c662d4000000000000000....0>; state=6
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_via.c:1284]:
parse_via_param(): Found param type 235, <rport> = <1169>; state=6
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_via.c:1284]:
parse_via_param(): Found param type 234, <received> = <xx.xx.xx.xx>;
state=16
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_via.c:2672]: parse_via():
end of header reached, state=5
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:513]:
parse_headers(): parse_headers: Via found, flags=2
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:515]:
parse_headers(): parse_headers: this is the first via
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[receive.c:152]: receive_msg(): After
parse_msg...
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:1072]: t_check_msg(): DEBUG:
t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_addr_spec.c:176]:
parse_to_param(): DEBUG: add_param: tag=74b38630e6be28bab2ebe17319971f33-c57e
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_addr_spec.c:893]:
parse_addr_spec(): end of header reached, state=29
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:190]:
get_hdr_field(): DEBUG: get_hdr_field: <To> [88]; uri=[sip:test1@test.com]
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:192]:
get_hdr_field(): DEBUG: to body [<sip:test1@test.com>]
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:170]:
get_hdr_field(): get_hdr_field: cseq <CSeq>: <10> <MESSAGE>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:949]: t_reply_matching(): DEBUG:
t_reply_matching: hash 58896 label 0 branch 0
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:1004]: t_reply_matching(): DEBUG:
t_reply_matching: reply matched (T=0x7f21ba974408)!
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:1141]: t_check_msg(): DEBUG:
t_check_msg: msg id=1 global id=1 T end=0x7f21ba974408
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:2206]: reply_received(): DEBUG:
reply_received: org. status uas=0, uac[0]=0 local=2 is_invite=0)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:1304]: t_should_relay_response():
->>>>>>>>> T_code=0, new_code=202
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:2086]: local_reply(): DEBUG:
local_reply: branch=0, save=0, winner=0
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:2123]: local_reply(): DEBUG: local
transaction completed
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_hooks.c:288]:
run_trans_callbacks_internal(): DBG: trans=0x7f21ba974408, callback type 1024, id 0
entered
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[msilo.c:1327]: m_tm_callback(): completed
with status 202 [mid: 139782841221704/4]
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[msilo.c:1340]: m_tm_callback(): message
<4> was sent successfully
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[ms_msg_list.c:236]: msg_list_set_flag():
mid:4 fl:4
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[msilo.c:1350]: m_tm_callback(): executing
event_route[msilo:on-delivered] (2)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:1663]: cleanup_uac_timers():
DEBUG: cleanup_uac_timers: RETR/FR timers reset
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[xavp.c:448]: xavp_destroy_list():
destroying xavp list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[receive.c:296]: receive_msg():
receive_msg: cleaning up
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike [timer.c:77]:
check_and_split_timer():
splitting 0x7f21ba98dab0(0x7f21ba7b15f8,0x7f21ba7b15f8)node=0x7f21ba98daa0
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike [timer.c:102]:
check_and_split_timer():
succ. to split (h=0x7f21ba7b15f8)(p=0x7f21ba7b15f8,n=0x7f21ba7b15f8)
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[pike_funcs.c:234]: clean_routine(): clean
node 0x7f21ba98daa0 (kids=(nil); hits=[0,0];leaf=[0,0])
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[pike_funcs.c:265]: clean_routine(): rmv
node 0x7f21ba98daa0[192]
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[ip_tree.c:364]: remove_node(): destroying
node 0x7f21ba98daa0
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG: <core>
[io_wait.h:617]: io_watch_del(): DBG:
io_watch_del (0x8eb2e0, 9, -1, 0x10) fd_no=2 called
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG: <core>
[tcp_read.c:1437]: release_tcpconn():
releasing con 0x7f21ba9420c0, state 1, fd=9, id=2
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG: <core>
[tcp_read.c:1438]: release_tcpconn():
extra_data 0x7f21ba941028
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG: <core>
[tcp_main.c:3385]: handle_tcp_child():
handle_tcp_child: reader response= 7f21ba9420c0, 1 from 2
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG: <core>
[io_wait.h:390]: io_watch_add(): DBG:
io_watch_add(0x893040, 28, 2, 0x7f21ba9420c0), fd_no=20
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG: <core>
[tcp_main.c:3515]: handle_tcp_child():
handle_tcp_child: CONN_RELEASE 0x7f21ba9420c0 refcnt= 1
Cheers,
Roberto Fichera.
Cheers,
Daniel
On 21/05/14 18:37, Roberto Fichera wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On 05/21/2014 09:08 AM, Roberto Fichera wrote:
Hi There,
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
> Hi Roberto,
Hi Peter,
> Did you ever figure out how to do it?
> I'd be interested too.
Not yet! I tried other ways, barely workarounds, but I guess I'll have to go into
this
quite soon because it is the straight way to go. The main problem is the lack of
my knowledge of kamailio API so I'll have to study a bit some code in order to
understand
how to use it.
BTW the idea is to trigger an event route were I'd like to set all the info
regarding
the dispatched message including the result of the delivering. I don't know if is
possible
but the best would be to set all the pseudo-variables so that such event route will be
in the right context of the given MSILO message.
So, any advice regarding the API would definitively help and put me in the right
direction.
Actually I've started to play with the above idea, so below you will find my current
implementation
which seems executed because I see the LM_DBG() log but the code within the event route
but
the corresponding script code does not.
Any help?
Cheers,
Roberto Fichera.
event_route [msilo:on-delivered] {
xlog("L_INFO", "MSILO event on-delivered <$fu> to
<$ru>\n");
}
diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
index 903b3cf..742c48d 100644
--- a/modules/msilo/msilo.c
+++ b/modules/msilo/msilo.c
@@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
return 0;
}
+/* where to go for the local request route ("msilo:on-delivered") */
+int msilo_event_on_delivered=-1; /* default disabled */
+
/**
* init module function
*/
@@ -480,6 +483,11 @@ static int mod_init(void)
if(ms_outbound_proxy.s!=NULL)
ms_outbound_proxy.len = strlen(ms_outbound_proxy.s);
+ /* check if the on-delivered route event exists or not */
+ msilo_event_on_delivered=route_lookup(&event_rt,
"msilo:on-delivered");
+ if (msilo_event_on_delivered>=0 &&
event_rt.rlist[msilo_event_on_delivered]==0)
+ msilo_event_on_delivered=-1; /* disable */
+
return 0;
}
@@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t, int type, struct tmcb_params
*ps)
LM_DBG("message <%d> was sent successfully\n",
*((int*)ps->param));
msg_list_set_flag(ml, *((int*)ps->param), MS_MSG_DONE);
+ /* execute the msilo:on-delivered event route */
+ if(unlikely(msilo_event_on_delivered>=0))
+ {
+ int sflag_bk;
+ int backup_route_type;
+ struct run_act_ctx ctx;
+
+ LM_DBG("executing event_route[msilo:on-delivered] (%d)\n",
msilo_event_on_delivered);
+
+ sflag_bk = getsflags();
+ backup_route_type = get_route_type();
+
+ set_route_type(EVENT_ROUTE);
+ init_run_actions_ctx(&ctx);
+ run_top_route(event_rt.rlist[msilo_event_on_delivered], ps->req,
&ctx);
+
+ set_route_type(backup_route_type);
+ setsflagsval(sflag_bk);
+ }
+
done:
return;
}
Cheers,
Roberto Fichera.
>
> Cheers,
> Peter
>
>
> On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera <kernel(a)tekno-soft.it
<mailto:kernel@tekno-soft.it>> wrote:
>
> On 04/17/2014 10:36 AM, Roberto Fichera wrote:
>
> Hi All,
>
> > On 04/16/2014 07:15 PM, Roberto Fichera wrote:
> >
> > Hi All,
> >
> >> On 04/16/2014 06:53 PM, Daniel-Constantin Mierla wrote:
> >>> Hello,
> >> Ciao Daniel,
> >>
> >>> most likely the messages are looped back, be sure you allow requests
from 'myself' without authentication.
> >>>
> >>> You can watch loopback interface with ngrep to see if the messages
are sent out.
> >> Yep! Allowing requests from myself solved the problem! Thanks!
> >>
> >> Another thing regarding MSILO, I would like to preserve some custom
header fields
> >> for both instant message and notification. How can I do it?
> > I was able to solve this issue too, pretty straight I mean, there is the
extra_hdrs_avp param
> > which did the trick. BTW, is there a way to send back the notification to
the sender that
> > the message has been sent correctly via m_dump(), so to get a 200 about the
given
> > m_dump()ed message?
> >
>
> I think that this can be solved in a different way, the idea is to add an
event_route for the msilo
> module so that we get notified for each m_dump()ed message about the given IM
status and
> then handle it in the cfg file. So, looking at the code within m_tm_callback() it
seems that it's
> right place where to add such feature. Since I'm not a kamailio developer but
I've quite long
> time experience in C coding, does anyone can show/point me to some example about
> how to do that?
>
> Thanks in advance,
> Roberto Fichera.
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:03 p.m.
Hello,
good that you sent a reminder -- I checked while offline traveling, but
then forgot to follow up.
I expect that ps->req is null in this case, because there is no request
received by kamailio. That results in xlog not doing anything.
In other words, I expect the event route being executed, just the action
inside is doesn't do anything in this case.
Cheers,
Daniel
On 26/05/14 11:40, Roberto Fichera wrote:
On 05/22/2014 09:08 AM, Roberto Fichera wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On 05/21/2014 11:15 PM, Daniel-Constantin Mierla
wrote:
> Hello,
Ciao Daniel,
have you had time to look at the problem below?
Cheers,
Roberto Fichera.
Ciao,
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users can you send the log messages printed with
debug=3?
Yes! Sure! Here it is:
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [receive.c:296]: receive_msg(): receive_msg: cleaning up
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:633]: parse_msg(): SIP Reply (status):
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:635]: parse_msg(): version: <SIP/2.0>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:637]: parse_msg(): status: <202>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:639]: parse_msg(): reason: <Accepted>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]: parse_via_param(): Found param type
232, <branch> = <z9hG4bK016e.a6c662d4000000000000000....0>; state=6
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]: parse_via_param(): Found param type
235, <rport> = <1169>; state=6
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]: parse_via_param(): Found param type
234, <received> = <xx.xx.xx.xx>; state=16
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:2672]: parse_via(): end of header reached,
state=5
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via
found, flags=2
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:515]: parse_headers(): parse_headers:
this is the first via
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [receive.c:152]: receive_msg(): After parse_msg...
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=1
global id=0 T start=0xffffffffffffffff
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG:
add_param: tag=74b38630e6be28bab2ebe17319971f33-c57e
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_addr_spec.c:893]: parse_addr_spec(): end of
header reached, state=29
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG:
get_hdr_field: <To> [88]; uri=[sip:test1@test.com]
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body
[<sip:test1@test.com>]
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field:
cseq <CSeq>: <10> <MESSAGE>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:949]: t_reply_matching(): DEBUG: t_reply_matching:
hash 58896 label 0 branch 0
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:1004]: t_reply_matching(): DEBUG: t_reply_matching:
reply matched (T=0x7f21ba974408)!
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=1
global id=1 T end=0x7f21ba974408
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:2206]: reply_received(): DEBUG: reply_received: org.
status uas=0, uac[0]=0 local=2 is_invite=0)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:1304]: t_should_relay_response(): ->>>>>>>>>
T_code=0,
new_code=202
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:2086]: local_reply(): DEBUG: local_reply: branch=0,
save=0, winner=0
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:2123]: local_reply(): DEBUG: local transaction completed
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG:
trans=0x7f21ba974408, callback type 1024, id 0 entered
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [msilo.c:1327]: m_tm_callback(): completed with status 202
[mid: 139782841221704/4]
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [msilo.c:1340]: m_tm_callback(): message <4> was sent successfully
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [ms_msg_list.c:236]: msg_list_set_flag(): mid:4 fl:4
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [msilo.c:1350]: m_tm_callback(): executing
event_route[msilo:on-delivered] (2)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:1663]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers:
RETR/FR timers reset
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [receive.c:296]: receive_msg(): receive_msg: cleaning up
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [timer.c:77]: check_and_split_timer(): splitting
0x7f21ba98dab0(0x7f21ba7b15f8,0x7f21ba7b15f8)node=0x7f21ba98daa0
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [timer.c:102]: check_and_split_timer(): succ. to split
(h=0x7f21ba7b15f8)(p=0x7f21ba7b15f8,n=0x7f21ba7b15f8)
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [pike_funcs.c:234]: clean_routine(): clean node 0x7f21ba98daa0
(kids=(nil); hits=[0,0];leaf=[0,0])
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [pike_funcs.c:265]: clean_routine(): rmv node 0x7f21ba98daa0[192]
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [ip_tree.c:364]: remove_node(): destroying node 0x7f21ba98daa0
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [io_wait.h:617]: io_watch_del(): DBG: io_watch_del (0x8eb2e0,
9, -1, 0x10) fd_no=2 called
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [tcp_read.c:1437]: release_tcpconn(): releasing con
0x7f21ba9420c0, state 1, fd=9, id=2
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [tcp_read.c:1438]: release_tcpconn(): extra_data 0x7f21ba941028
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [tcp_main.c:3385]: handle_tcp_child(): handle_tcp_child:
reader response= 7f21ba9420c0, 1 from 2
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [io_wait.h:390]: io_watch_add(): DBG: io_watch_add(0x893040,
28, 2, 0x7f21ba9420c0), fd_no=20
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [tcp_main.c:3515]: handle_tcp_child(): handle_tcp_child:
CONN_RELEASE 0x7f21ba9420c0 refcnt= 1
Cheers,
Roberto Fichera.
Cheers,
Daniel
On 21/05/14 18:37, Roberto Fichera wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On 05/21/2014 09:08 AM, Roberto Fichera wrote:
Hi There,
> On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
>> Hi Roberto,
>
> Hi Peter,
>
>> Did you ever figure out how to do it?
>> I'd be interested too.
>
> Not yet! I tried other ways, barely workarounds, but I guess I'll
> have to go into this
> quite soon because it is the straight way to go. The main problem
> is the lack of
> my knowledge of kamailio API so I'll have to study a bit some code
> in order to understand
> how to use it.
>
> BTW the idea is to trigger an event route were I'd like to set all
> the info regarding
> the dispatched message including the result of the delivering. I
> don't know if is possible
> but the best would be to set all the pseudo-variables so that such
> event route will be
> in the right context of the given MSILO message.
>
> So, any advice regarding the API would definitively help and put
> me in the right direction.
Actually I've started to play with the above idea, so below you
will find my current implementation
which seems executed because I see the LM_DBG() log but the code
within the event route but
the corresponding script code does not.
Any help?
Cheers,
Roberto Fichera.
event_route [msilo:on-delivered] {
xlog("L_INFO", "MSILO event on-delivered <$fu> to
<$ru>\n");
}
diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
index 903b3cf..742c48d 100644
--- a/modules/msilo/msilo.c
+++ b/modules/msilo/msilo.c
@@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
return 0;
}
+/* where to go for the local request route ("msilo:on-delivered") */
+int msilo_event_on_delivered=-1; /* default disabled */
+
/**
* init module function
*/
@@ -480,6 +483,11 @@ static int mod_init(void)
if(ms_outbound_proxy.s!=NULL)
ms_outbound_proxy.len = strlen(ms_outbound_proxy.s);
+ /* check if the on-delivered route event exists or not */
+ msilo_event_on_delivered=route_lookup(&event_rt,
"msilo:on-delivered");
+ if (msilo_event_on_delivered>=0 &&
event_rt.rlist[msilo_event_on_delivered]==0)
+ msilo_event_on_delivered=-1; /* disable */
+
return 0;
}
@@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t, int
type, struct tmcb_params *ps)
LM_DBG("message <%d> was sent successfully\n",
*((int*)ps->param));
msg_list_set_flag(ml, *((int*)ps->param), MS_MSG_DONE);
+ /* execute the msilo:on-delivered event route */
+ if(unlikely(msilo_event_on_delivered>=0))
+ {
+ int sflag_bk;
+ int backup_route_type;
+ struct run_act_ctx ctx;
+
+ LM_DBG("executing event_route[msilo:on-delivered]
(%d)\n", msilo_event_on_delivered);
+
+ sflag_bk = getsflags();
+ backup_route_type = get_route_type();
+
+ set_route_type(EVENT_ROUTE);
+ init_run_actions_ctx(&ctx);
+ run_top_route(event_rt.rlist[msilo_event_on_delivered], ps->req,
&ctx);
+
+ set_route_type(backup_route_type);
+ setsflagsval(sflag_bk);
+ }
+
done:
return;
}
>
> Cheers,
> Roberto Fichera.
>
>>
>> Cheers,
>> Peter
>>
>>
>> On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera
>> <kernel(a)tekno-soft.it <mailto:kernel@tekno-soft.it>> wrote:
>>
>> On 04/17/2014 10:36 AM, Roberto Fichera wrote:
>>
>> Hi All,
>>
>> > On 04/16/2014 07:15 PM, Roberto Fichera wrote:
>> >
>> > Hi All,
>> >
>> >> On 04/16/2014 06:53 PM, Daniel-Constantin Mierla wrote:
>> >>> Hello,
>> >> Ciao Daniel,
>> >>
>> >>> most likely the messages are looped back, be sure you
>> allow requests from 'myself' without authentication.
>> >>>
>> >>> You can watch loopback interface with ngrep to see if the
>> messages are sent out.
>> >> Yep! Allowing requests from myself solved the problem! Thanks!
>> >>
>> >> Another thing regarding MSILO, I would like to preserve
>> some custom header fields
>> >> for both instant message and notification. How can I do it?
>> > I was able to solve this issue too, pretty straight I mean,
>> there is the extra_hdrs_avp param
>> > which did the trick. BTW, is there a way to send back the
>> notification to the sender that
>> > the message has been sent correctly via m_dump(), so to get
>> a 200 about the given
>> > m_dump()ed message?
>> >
>>
>> I think that this can be solved in a different way, the idea
>> is to add an event_route for the msilo
>> module so that we get notified for each m_dump()ed message
>> about the given IM status and
>> then handle it in the cfg file. So, looking at the code
>> within m_tm_callback() it seems that it's
>> right place where to add such feature. Since I'm not a
>> kamailio developer but I've quite long
>> time experience in C coding, does anyone can show/point me to
>> some example about
>> how to do that?
>>
>> Thanks in advance,
>> Roberto Fichera.
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>> mailing list
>> sr-users(a)lists.sip-router.org
>> <mailto:sr-users@lists.sip-router.org>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:13 p.m.
On 05/26/2014 12:03 PM, Daniel-Constantin Mierla wrote:
Hello,
Ciao!
good that you sent a reminder -- I checked while offline traveling, but then forgot to
follow up.
I expect that ps->req is null in this case, because there is no request received by
kamailio. That results in xlog not
doing anything.
In other words, I expect the event route being executed, just the action inside is
doesn't do anything in this case.
Does this mean that I'll have to set a "faked" ps->req in order to get
the event route executed?
Cheers,
Roberto Fichera.
>
> Cheers,
> Daniel
>
> On 26/05/14 11:40, Roberto Fichera wrote:
>> On 05/22/2014 09:08 AM, Roberto Fichera wrote:
>>> On 05/21/2014 11:15 PM, Daniel-Constantin Mierla wrote:
>>> Hello,
>>
>> Ciao Daniel,
>>
>> have you had time to look at the problem below?
>>
>> Cheers,
>> Roberto Fichera.
>>
>>>
>>> Ciao,
>>>
>>>> can you send the log messages printed with debug=3?
>>>
>>> Yes! Sure! Here it is:
>>>
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [receive.c:296]: receive_msg():
>>> receive_msg: cleaning up
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:633]: parse_msg():
>>> SIP Reply (status):
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:635]:
>>> parse_msg(): version: <SIP/2.0>
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:637]:
>>> parse_msg(): status: <202>
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:639]:
>>> parse_msg(): reason: <Accepted>
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]:
>>> parse_via_param(): Found param type 232, <branch> =
<z9hG4bK016e.a6c662d4000000000000000....0>; state=6
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]:
>>> parse_via_param(): Found param type 235, <rport> = <1169>;
state=6
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]:
>>> parse_via_param(): Found param type 234, <received> =
<xx.xx.xx.xx>; state=16
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:2672]: parse_via():
>>> end of header reached, state=5
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:513]:
>>> parse_headers(): parse_headers: Via found, flags=2
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:515]:
>>> parse_headers(): parse_headers: this is the first via
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [receive.c:152]: receive_msg(): After
>>> parse_msg...
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:1072]: t_check_msg(): DEBUG:
>>> t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_addr_spec.c:176]:
>>> parse_to_param(): DEBUG: add_param:
tag=74b38630e6be28bab2ebe17319971f33-c57e
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_addr_spec.c:893]:
>>> parse_addr_spec(): end of header reached, state=29
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:190]:
>>> get_hdr_field(): DEBUG: get_hdr_field: <To> [88];
uri=[sip:test1@test.com]
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:192]:
>>> get_hdr_field(): DEBUG: to body [<sip:test1@test.com>]
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:170]:
>>> get_hdr_field(): get_hdr_field: cseq <CSeq>: <10>
<MESSAGE>
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:949]: t_reply_matching():
>>> DEBUG: t_reply_matching: hash 58896 label 0 branch 0
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:1004]: t_reply_matching():
>>> DEBUG: t_reply_matching: reply matched (T=0x7f21ba974408)!
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:1141]: t_check_msg(): DEBUG:
>>> t_check_msg: msg id=1 global id=1 T end=0x7f21ba974408
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:2206]: reply_received(): DEBUG:
>>> reply_received: org. status uas=0, uac[0]=0 local=2 is_invite=0)
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:1304]:
>>> t_should_relay_response(): ->>>>>>>>> T_code=0,
new_code=202
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:2086]: local_reply(): DEBUG:
>>> local_reply: branch=0, save=0, winner=0
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:2123]: local_reply(): DEBUG:
>>> local transaction completed
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_hooks.c:288]:
>>> run_trans_callbacks_internal(): DBG: trans=0x7f21ba974408, callback type
1024, id 0 entered
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[msilo.c:1327]: m_tm_callback():
>>> completed with status 202 [mid: 139782841221704/4]
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[msilo.c:1340]: m_tm_callback(): message
>>> <4> was sent successfully
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[ms_msg_list.c:236]:
>>> msg_list_set_flag(): mid:4 fl:4
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[msilo.c:1350]: m_tm_callback():
>>> executing event_route[msilo:on-delivered] (2)
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:1663]: cleanup_uac_timers():
>>> DEBUG: cleanup_uac_timers: RETR/FR timers reset
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list():
>>> DEBUG:destroy_avp_list: destroying list (nil)
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list():
>>> DEBUG:destroy_avp_list: destroying list (nil)
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list():
>>> DEBUG:destroy_avp_list: destroying list (nil)
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list():
>>> DEBUG:destroy_avp_list: destroying list (nil)
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list():
>>> DEBUG:destroy_avp_list: destroying list (nil)
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list():
>>> DEBUG:destroy_avp_list: destroying list (nil)
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [xavp.c:448]: xavp_destroy_list():
>>> destroying xavp list (nil)
>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [receive.c:296]: receive_msg():
>>> receive_msg: cleaning up
>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[timer.c:77]: check_and_split_timer():
>>> splitting 0x7f21ba98dab0(0x7f21ba7b15f8,0x7f21ba7b15f8)node=0x7f21ba98daa0
>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[timer.c:102]: check_and_split_timer():
>>> succ. to split (h=0x7f21ba7b15f8)(p=0x7f21ba7b15f8,n=0x7f21ba7b15f8)
>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[pike_funcs.c:234]: clean_routine():
>>> clean node 0x7f21ba98daa0 (kids=(nil); hits=[0,0];leaf=[0,0])
>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[pike_funcs.c:265]: clean_routine(): rmv
>>> node 0x7f21ba98daa0[192]
>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[ip_tree.c:364]: remove_node():
>>> destroying node 0x7f21ba98daa0
>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [io_wait.h:617]: io_watch_del(): DBG:
>>> io_watch_del (0x8eb2e0, 9, -1, 0x10) fd_no=2 called
>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [tcp_read.c:1437]: release_tcpconn():
>>> releasing con 0x7f21ba9420c0, state 1, fd=9, id=2
>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [tcp_read.c:1438]: release_tcpconn():
>>> extra_data 0x7f21ba941028
>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [tcp_main.c:3385]: handle_tcp_child():
>>> handle_tcp_child: reader response= 7f21ba9420c0, 1 from 2
>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [io_wait.h:390]: io_watch_add(): DBG:
>>> io_watch_add(0x893040, 28, 2, 0x7f21ba9420c0), fd_no=20
>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [tcp_main.c:3515]: handle_tcp_child():
>>> handle_tcp_child: CONN_RELEASE 0x7f21ba9420c0 refcnt= 1
>>>
>>> Cheers,
>>> Roberto Fichera.
>>>
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 21/05/14 18:37, Roberto Fichera wrote:
>>>>> On 05/21/2014 09:08 AM, Roberto Fichera wrote:
>>>>>
>>>>> Hi There,
>>>>>
>>>>>> On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
>>>>>>> Hi Roberto,
>>>>>>
>>>>>> Hi Peter,
>>>>>>
>>>>>>> Did you ever figure out how to do it?
>>>>>>> I'd be interested too.
>>>>>>
>>>>>> Not yet! I tried other ways, barely workarounds, but I guess
I'll have to go into this
>>>>>> quite soon because it is the straight way to go. The main problem
is the lack of
>>>>>> my knowledge of kamailio API so I'll have to study a bit some
code in order to understand
>>>>>> how to use it.
>>>>>>
>>>>>> BTW the idea is to trigger an event route were I'd like to
set all the info regarding
>>>>>> the dispatched message including the result of the delivering. I
don't know if is possible
>>>>>> but the best would be to set all the pseudo-variables so that
such event route will be
>>>>>> in the right context of the given MSILO message.
>>>>>>
>>>>>> So, any advice regarding the API would definitively help and put
me in the right direction.
>>>>>
>>>>> Actually I've started to play with the above idea, so below you
will find my current implementation
>>>>> which seems executed because I see the LM_DBG() log but the code
within the event route but
>>>>> the corresponding script code does not.
>>>>>
>>>>> Any help?
>>>>>
>>>>> Cheers,
>>>>> Roberto Fichera.
>>>>>
>>>>>
>>>>> event_route [msilo:on-delivered] {
>>>>> xlog("L_INFO", "MSILO event on-delivered <$fu>
to <$ru>\n");
>>>>> }
>>>>>
>>>>>
>>>>> diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
>>>>> index 903b3cf..742c48d 100644
>>>>> --- a/modules/msilo/msilo.c
>>>>> +++ b/modules/msilo/msilo.c
>>>>> @@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
>>>>> return 0;
>>>>> }
>>>>>
>>>>> +/* where to go for the local request route
("msilo:on-delivered") */
>>>>> +int msilo_event_on_delivered=-1; /* default disabled */
>>>>> +
>>>>> /**
>>>>> * init module function
>>>>> */
>>>>> @@ -480,6 +483,11 @@ static int mod_init(void)
>>>>> if(ms_outbound_proxy.s!=NULL)
>>>>> ms_outbound_proxy.len = strlen(ms_outbound_proxy.s);
>>>>>
>>>>> + /* check if the on-delivered route event exists or not */
>>>>> + msilo_event_on_delivered=route_lookup(&event_rt,
"msilo:on-delivered");
>>>>> + if (msilo_event_on_delivered>=0 &&
event_rt.rlist[msilo_event_on_delivered]==0)
>>>>> + msilo_event_on_delivered=-1; /* disable */
>>>>> +
>>>>> return 0;
>>>>> }
>>>>>
>>>>> @@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t, int type,
struct tmcb_params *ps)
>>>>> LM_DBG("message <%d> was sent
successfully\n", *((int*)ps->param));
>>>>> msg_list_set_flag(ml, *((int*)ps->param), MS_MSG_DONE);
>>>>>
>>>>> + /* execute the msilo:on-delivered event route */
>>>>> + if(unlikely(msilo_event_on_delivered>=0))
>>>>> + {
>>>>> + int sflag_bk;
>>>>> + int backup_route_type;
>>>>> + struct run_act_ctx ctx;
>>>>> +
>>>>> + LM_DBG("executing
event_route[msilo:on-delivered] (%d)\n", msilo_event_on_delivered);
>>>>> +
>>>>> + sflag_bk = getsflags();
>>>>> + backup_route_type = get_route_type();
>>>>> +
>>>>> + set_route_type(EVENT_ROUTE);
>>>>> + init_run_actions_ctx(&ctx);
>>>>> +
run_top_route(event_rt.rlist[msilo_event_on_delivered], ps->req, &ctx);
>>>>> +
>>>>> + set_route_type(backup_route_type);
>>>>> + setsflagsval(sflag_bk);
>>>>> + }
>>>>> +
>>>>> done:
>>>>> return;
>>>>> }
>>>>>
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Roberto Fichera.
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Peter
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera
<kernel(a)tekno-soft.it <mailto:kernel@tekno-soft.it>> wrote:
>>>>>>>
>>>>>>> On 04/17/2014 10:36 AM, Roberto Fichera wrote:
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> > On 04/16/2014 07:15 PM, Roberto Fichera wrote:
>>>>>>> >
>>>>>>> > Hi All,
>>>>>>> >
>>>>>>> >> On 04/16/2014 06:53 PM, Daniel-Constantin Mierla
wrote:
>>>>>>> >>
Hello,
>>>>>>> >> Ciao Daniel,
>>>>>>> >>
>>>>>>> >>> most likely the messages are looped back, be
sure you allow requests from 'myself' without authentication.
>>>>>>> >>>
>>>>>>> >>> You can watch loopback interface with ngrep
to see if the messages are sent out.
>>>>>>> >> Yep! Allowing requests from myself solved the
problem! Thanks!
>>>>>>> >>
>>>>>>> >> Another thing regarding MSILO, I would like to
preserve some custom header fields
>>>>>>> >> for both instant message and notification. How
can I do it?
>>>>>>> > I was able to solve this issue too, pretty straight
I mean, there is the extra_hdrs_avp param
>>>>>>> > which did the trick. BTW, is there a way to send
back the notification to the sender that
>>>>>>> > the message has been sent correctly via m_dump(), so
to get a 200 about the given
>>>>>>> > m_dump()ed message?
>>>>>>> >
>>>>>>>
>>>>>>> I think that this can be solved in a different way, the
idea is to add an event_route for the msilo
>>>>>>> module so that we get notified for each m_dump()ed
message about the given IM status and
>>>>>>> then handle it in the cfg file. So, looking at the code
within m_tm_callback() it seems that it's
>>>>>>> right place where to add such feature. Since I'm not
a kamailio developer but I've quite long
>>>>>>> time experience in C coding, does anyone can show/point
me to some example about
>>>>>>> how to do that?
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>> Roberto Fichera.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users mailing list
>>>>>>> sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
>>>>>>>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
>>>>>>> sr-users(a)lists.sip-router.org
>>>>>>>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
>>>>>> sr-users(a)lists.sip-router.org
>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
>>>>> sr-users(a)lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>> --
>>>> Daniel-Constantin Mierla - http://www.asipto.com
>>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users(a)lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:17 p.m.
Hello,
On 26/05/14 12:13, Roberto Fichera wrote:
On 05/26/2014 12:03 PM, Daniel-Constantin Mierla
wrote:
that's the safe way. The event route is executed, but many functions
that you can use inside config routing blocks require a non-null sip
message structure. It is the case of xlog() for example, which simply
returns -1 if request is null.
Cheers, Daniel
Hello,
Ciao!
good that you sent a reminder -- I checked while offline traveling,
but then forgot to follow up.
I expect that ps->req is null in this case, because there is no
request received by kamailio. That results in xlog not doing anything.
In other words, I expect the event route being executed, just the
action inside is doesn't do anything in this case.
Does this mean that I'll have to set a "faked" ps->req in order to get
the event route executed?
Cheers,
Roberto Fichera.
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Cheers,
Daniel
On 26/05/14 11:40, Roberto Fichera wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On 05/22/2014 09:08 AM, Roberto Fichera wrote:
--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On 05/21/2014 11:15 PM, Daniel-Constantin Mierla
wrote:
> Hello,
Ciao Daniel,
have you had time to look at the problem below?
Cheers,
Roberto Fichera.
Ciao,
> can you send the log messages printed with debug=3?
Yes! Sure! Here it is:
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8454]:
DEBUG: <core> [receive.c:296]: receive_msg(): receive_msg: cleaning up
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/msg_parser.c:633]: parse_msg(): SIP Reply
(status):
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/msg_parser.c:635]: parse_msg(): version:
<SIP/2.0>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/msg_parser.c:637]: parse_msg(): status: <202>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/msg_parser.c:639]: parse_msg(): reason:
<Accepted>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found
param type 232, <branch> =
<z9hG4bK016e.a6c662d4000000000000000....0>; state=6
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found
param type 235, <rport> = <1169>; state=6
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found
param type 234, <received> = <xx.xx.xx.xx>; state=16
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header
reached, state=5
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/msg_parser.c:513]: parse_headers():
parse_headers: Via found, flags=2
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/msg_parser.c:515]: parse_headers():
parse_headers: this is the first via
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [receive.c:152]: receive_msg(): After parse_msg...
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg
id=1 global id=0 T start=0xffffffffffffffff
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param():
DEBUG: add_param: tag=74b38630e6be28bab2ebe17319971f33-c57e
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/parse_addr_spec.c:893]: parse_addr_spec():
end of header reached, state=29
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG:
get_hdr_field: <To> [88]; uri=[sip:test1@test.com]
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to
body [<sip:test1@test.com>]
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field():
get_hdr_field: cseq <CSeq>: <10> <MESSAGE>
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG:
t_reply_matching: hash 58896 label 0 branch 0
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: tm [t_lookup.c:1004]: t_reply_matching(): DEBUG:
t_reply_matching: reply matched (T=0x7f21ba974408)!
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg
id=1 global id=1 T end=0x7f21ba974408
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: tm [t_reply.c:2206]: reply_received(): DEBUG:
reply_received: org. status uas=0, uac[0]=0 local=2 is_invite=0)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: tm [t_reply.c:1304]: t_should_relay_response():
->>>>>>>>>
T_code=0, new_code=202
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: tm [t_reply.c:2086]: local_reply(): DEBUG: local_reply:
branch=0, save=0, winner=0
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: tm [t_reply.c:2123]: local_reply(): DEBUG: local transaction
completed
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG:
trans=0x7f21ba974408, callback type 1024, id 0 entered
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: msilo [msilo.c:1327]: m_tm_callback(): completed with status
202 [mid: 139782841221704/4]
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: msilo [msilo.c:1340]: m_tm_callback(): message <4> was sent
successfully
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: msilo [ms_msg_list.c:236]: msg_list_set_flag(): mid:4 fl:4
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: msilo [msilo.c:1350]: m_tm_callback(): executing
event_route[msilo:on-delivered] (2)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: tm [t_reply.c:1663]: cleanup_uac_timers(): DEBUG:
cleanup_uac_timers: RETR/FR timers reset
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [usr_avp.c:644]: destroy_avp_list():
DEBUG:destroy_avp_list: destroying list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp
list (nil)
May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
DEBUG: <core> [receive.c:296]: receive_msg(): receive_msg: cleaning up
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]:
DEBUG: pike [timer.c:77]: check_and_split_timer(): splitting
0x7f21ba98dab0(0x7f21ba7b15f8,0x7f21ba7b15f8)node=0x7f21ba98daa0
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]:
DEBUG: pike [timer.c:102]: check_and_split_timer(): succ. to split
(h=0x7f21ba7b15f8)(p=0x7f21ba7b15f8,n=0x7f21ba7b15f8)
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]:
DEBUG: pike [pike_funcs.c:234]: clean_routine(): clean node
0x7f21ba98daa0 (kids=(nil); hits=[0,0];leaf=[0,0])
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]:
DEBUG: pike [pike_funcs.c:265]: clean_routine(): rmv node
0x7f21ba98daa0[192]
May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]:
DEBUG: pike [ip_tree.c:364]: remove_node(): destroying node
0x7f21ba98daa0
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]:
DEBUG: <core> [io_wait.h:617]: io_watch_del(): DBG: io_watch_del
(0x8eb2e0, 9, -1, 0x10) fd_no=2 called
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]:
DEBUG: <core> [tcp_read.c:1437]: release_tcpconn(): releasing con
0x7f21ba9420c0, state 1, fd=9, id=2
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]:
DEBUG: <core> [tcp_read.c:1438]: release_tcpconn(): extra_data
0x7f21ba941028
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]:
DEBUG: <core> [tcp_main.c:3385]: handle_tcp_child():
handle_tcp_child: reader response= 7f21ba9420c0, 1 from 2
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]:
DEBUG: <core> [io_wait.h:390]: io_watch_add(): DBG:
io_watch_add(0x893040, 28, 2, 0x7f21ba9420c0), fd_no=20
May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]:
DEBUG: <core> [tcp_main.c:3515]: handle_tcp_child():
handle_tcp_child: CONN_RELEASE 0x7f21ba9420c0 refcnt= 1
Cheers,
Roberto Fichera.
>
> Cheers,
> Daniel
>
> On 21/05/14 18:37, Roberto Fichera wrote:
>> On 05/21/2014 09:08 AM, Roberto Fichera wrote:
>>
>> Hi There,
>>
>>> On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
>>>> Hi Roberto,
>>>
>>> Hi Peter,
>>>
>>>> Did you ever figure out how to do it?
>>>> I'd be interested too.
>>>
>>> Not yet! I tried other ways, barely workarounds, but I guess
>>> I'll have to go into this
>>> quite soon because it is the straight way to go. The main
>>> problem is the lack of
>>> my knowledge of kamailio API so I'll have to study a bit some
>>> code in order to understand
>>> how to use it.
>>>
>>> BTW the idea is to trigger an event route were I'd like to set
>>> all the info regarding
>>> the dispatched message including the result of the delivering. I
>>> don't know if is possible
>>> but the best would be to set all the pseudo-variables so that
>>> such event route will be
>>> in the right context of the given MSILO message.
>>>
>>> So, any advice regarding the API would definitively help and put
>>> me in the right direction.
>>
>> Actually I've started to play with the above idea, so below you
>> will find my current implementation
>> which seems executed because I see the LM_DBG() log but the code
>> within the event route but
>> the corresponding script code does not.
>>
>> Any help?
>>
>> Cheers,
>> Roberto Fichera.
>>
>>
>> event_route [msilo:on-delivered] {
>> xlog("L_INFO", "MSILO event on-delivered <$fu> to
<$ru>\n");
>> }
>>
>>
>> diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
>> index 903b3cf..742c48d 100644
>> --- a/modules/msilo/msilo.c
>> +++ b/modules/msilo/msilo.c
>> @@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
>> return 0;
>> }
>>
>> +/* where to go for the local request route ("msilo:on-delivered") */
>> +int msilo_event_on_delivered=-1; /* default disabled */
>> +
>> /**
>> * init module function
>> */
>> @@ -480,6 +483,11 @@ static int mod_init(void)
>> if(ms_outbound_proxy.s!=NULL)
>> ms_outbound_proxy.len = strlen(ms_outbound_proxy.s);
>>
>> + /* check if the on-delivered route event exists or not */
>> + msilo_event_on_delivered=route_lookup(&event_rt,
>> "msilo:on-delivered");
>> + if (msilo_event_on_delivered>=0 &&
>> event_rt.rlist[msilo_event_on_delivered]==0)
>> + msilo_event_on_delivered=-1; /* disable */
>> +
>> return 0;
>> }
>>
>> @@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t, int
>> type, struct tmcb_params *ps)
>> LM_DBG("message <%d> was sent successfully\n",
>> *((int*)ps->param));
>> msg_list_set_flag(ml, *((int*)ps->param), MS_MSG_DONE);
>>
>> + /* execute the msilo:on-delivered event route */
>> + if(unlikely(msilo_event_on_delivered>=0))
>> + {
>> + int sflag_bk;
>> + int backup_route_type;
>> + struct run_act_ctx ctx;
>> +
>> + LM_DBG("executing
>> event_route[msilo:on-delivered] (%d)\n", msilo_event_on_delivered);
>> +
>> + sflag_bk = getsflags();
>> + backup_route_type = get_route_type();
>> +
>> + set_route_type(EVENT_ROUTE);
>> + init_run_actions_ctx(&ctx);
>> + run_top_route(event_rt.rlist[msilo_event_on_delivered],
>> ps->req, &ctx);
>> +
>> + set_route_type(backup_route_type);
>> + setsflagsval(sflag_bk);
>> + }
>> +
>> done:
>> return;
>> }
>>
>>
>>>
>>> Cheers,
>>> Roberto Fichera.
>>>
>>>>
>>>> Cheers,
>>>> Peter
>>>>
>>>>
>>>> On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera
>>>> <kernel(a)tekno-soft.it <mailto:kernel@tekno-soft.it>> wrote:
>>>>
>>>> On 04/17/2014 10:36 AM, Roberto Fichera wrote:
>>>>
>>>> Hi All,
>>>>
>>>> > On 04/16/2014 07:15 PM, Roberto Fichera wrote:
>>>> >
>>>> > Hi All,
>>>> >
>>>> >> On 04/16/2014 06:53 PM, Daniel-Constantin Mierla wrote:
>>>> >>> Hello,
>>>> >> Ciao Daniel,
>>>> >>
>>>> >>> most likely the messages are looped back, be sure you
>>>> allow requests from 'myself' without authentication.
>>>> >>>
>>>> >>> You can watch loopback interface with ngrep to see if
>>>> the messages are sent out.
>>>> >> Yep! Allowing requests from myself solved the problem!
>>>> Thanks!
>>>> >>
>>>> >> Another thing regarding MSILO, I would like to preserve
>>>> some custom header fields
>>>> >> for both instant message and notification. How can I do it?
>>>> > I was able to solve this issue too, pretty straight I
>>>> mean, there is the extra_hdrs_avp param
>>>> > which did the trick. BTW, is there a way to send back the
>>>> notification to the sender that
>>>> > the message has been sent correctly via m_dump(), so to
>>>> get a 200 about the given
>>>> > m_dump()ed message?
>>>> >
>>>>
>>>> I think that this can be solved in a different way, the
>>>> idea is to add an event_route for the msilo
>>>> module so that we get notified for each m_dump()ed message
>>>> about the given IM status and
>>>> then handle it in the cfg file. So, looking at the code
>>>> within m_tm_callback() it seems that it's
>>>> right place where to add such feature. Since I'm not a
>>>> kamailio developer but I've quite long
>>>> time experience in C coding, does anyone can show/point me
>>>> to some example about
>>>> how to do that?
>>>>
>>>> Thanks in advance,
>>>> Roberto Fichera.
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>>>> mailing list
>>>> sr-users(a)lists.sip-router.org
>>>> <mailto:sr-users@lists.sip-router.org>
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users(a)lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla -http://www.asipto.com
> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:25 p.m.
On 05/26/2014 12:17 PM, Daniel-Constantin Mierla wrote:
Ciao,
Hello,
On 26/05/14 12:13, Roberto Fichera wrote:
Ok! Can you suggest the safest and reasonable way to setup the request for this case?
Cheers,
Roberto Fichera.
On 05/26/2014 12:03 PM, Daniel-Constantin Mierla
wrote:
that's the safe way. The event route is executed, but many functions that you can use
inside config routing blocks
require a non-null sip message structure. It is the case of xlog() for example, which
simply returns -1 if request is
null. Hello,
Ciao!
good that you sent a reminder -- I checked while offline traveling, but then forgot to
follow up.
I expect that ps->req is null in this case, because there is no request received by
kamailio. That results in xlog
not doing anything.
In other words, I expect the event route being executed, just the action inside is
doesn't do anything in this case.
Does this mean that I'll have to set a "faked" ps->req in order to get
the event route executed?
Cheers, Daniel
Cheers,
Roberto Fichera.
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Cheers,
Daniel
On 26/05/14 11:40, Roberto Fichera wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On 05/22/2014 09:08 AM, Roberto Fichera wrote:
> On 05/21/2014 11:15 PM, Daniel-Constantin Mierla wrote:
>> Hello,
Ciao Daniel,
have you had time to look at the problem below?
Cheers,
Roberto Fichera.
>
> Ciao,
>
>> can you send the log messages printed with debug=3?
>
> Yes! Sure! Here it is:
>
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG: <core>
[receive.c:296]: receive_msg():
> receive_msg: cleaning up
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:633]:
> parse_msg(): SIP Reply (status):
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:635]:
> parse_msg(): version: <SIP/2.0>
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:637]:
> parse_msg(): status: <202>
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:639]:
> parse_msg(): reason: <Accepted>
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_via.c:1284]:
> parse_via_param(): Found param type 232, <branch> =
<z9hG4bK016e.a6c662d4000000000000000....0>; state=6
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_via.c:1284]:
> parse_via_param(): Found param type 235, <rport> = <1169>; state=6
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_via.c:1284]:
> parse_via_param(): Found param type 234, <received> = <xx.xx.xx.xx>;
state=16
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_via.c:2672]:
> parse_via(): end of header reached, state=5
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:513]:
> parse_headers(): parse_headers: Via found, flags=2
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:515]:
> parse_headers(): parse_headers: this is the first via
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[receive.c:152]: receive_msg(): After
> parse_msg...
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:1072]: t_check_msg(): DEBUG:
> t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_addr_spec.c:176]:
> parse_to_param(): DEBUG: add_param: tag=74b38630e6be28bab2ebe17319971f33-c57e
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/parse_addr_spec.c:893]:
> parse_addr_spec(): end of header reached, state=29
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:190]:
> get_hdr_field(): DEBUG: get_hdr_field: <To> [88]; uri=[sip:test1@test.com]
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:192]:
> get_hdr_field(): DEBUG: to body [<sip:test1@test.com>]
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[parser/msg_parser.c:170]:
> get_hdr_field(): get_hdr_field: cseq <CSeq>: <10> <MESSAGE>
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:949]: t_reply_matching():
> DEBUG: t_reply_matching: hash 58896 label 0 branch 0
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:1004]: t_reply_matching():
> DEBUG: t_reply_matching: reply matched (T=0x7f21ba974408)!
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_lookup.c:1141]: t_check_msg(): DEBUG:
> t_check_msg: msg id=1 global id=1 T end=0x7f21ba974408
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:2206]: reply_received():
> DEBUG: reply_received: org. status uas=0, uac[0]=0 local=2 is_invite=0)
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:1304]:
> t_should_relay_response(): ->>>>>>>>> T_code=0,
new_code=202
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:2086]: local_reply(): DEBUG:
> local_reply: branch=0, save=0, winner=0
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:2123]: local_reply(): DEBUG:
> local transaction completed
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_hooks.c:288]:
> run_trans_callbacks_internal(): DBG: trans=0x7f21ba974408, callback type 1024, id 0
entered
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[msilo.c:1327]: m_tm_callback():
> completed with status 202 [mid: 139782841221704/4]
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[msilo.c:1340]: m_tm_callback():
> message <4> was sent successfully
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[ms_msg_list.c:236]:
> msg_list_set_flag(): mid:4 fl:4
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: msilo
[msilo.c:1350]: m_tm_callback():
> executing event_route[msilo:on-delivered] (2)
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: tm
[t_reply.c:1663]: cleanup_uac_timers():
> DEBUG: cleanup_uac_timers: RETR/FR timers reset
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
> DEBUG:destroy_avp_list: destroying list (nil)
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
> DEBUG:destroy_avp_list: destroying list (nil)
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
> DEBUG:destroy_avp_list: destroying list (nil)
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
> DEBUG:destroy_avp_list: destroying list (nil)
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
> DEBUG:destroy_avp_list: destroying list (nil)
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list():
> DEBUG:destroy_avp_list: destroying list (nil)
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[xavp.c:448]: xavp_destroy_list():
> destroying xavp list (nil)
> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG: <core>
[receive.c:296]: receive_msg():
> receive_msg: cleaning up
> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[timer.c:77]: check_and_split_timer():
> splitting 0x7f21ba98dab0(0x7f21ba7b15f8,0x7f21ba7b15f8)node=0x7f21ba98daa0
> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[timer.c:102]: check_and_split_timer():
> succ. to split (h=0x7f21ba7b15f8)(p=0x7f21ba7b15f8,n=0x7f21ba7b15f8)
> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[pike_funcs.c:234]: clean_routine():
> clean node 0x7f21ba98daa0 (kids=(nil); hits=[0,0];leaf=[0,0])
> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[pike_funcs.c:265]: clean_routine():
> rmv node 0x7f21ba98daa0[192]
> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG: pike
[ip_tree.c:364]: remove_node():
> destroying node 0x7f21ba98daa0
> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG: <core>
[io_wait.h:617]: io_watch_del(): DBG:
> io_watch_del (0x8eb2e0, 9, -1, 0x10) fd_no=2 called
> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG: <core>
[tcp_read.c:1437]: release_tcpconn():
> releasing con 0x7f21ba9420c0, state 1, fd=9, id=2
> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG: <core>
[tcp_read.c:1438]:
> release_tcpconn(): extra_data 0x7f21ba941028
> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG: <core>
[tcp_main.c:3385]:
> handle_tcp_child(): handle_tcp_child: reader response= 7f21ba9420c0, 1 from 2
> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG: <core>
[io_wait.h:390]: io_watch_add(): DBG:
> io_watch_add(0x893040, 28, 2, 0x7f21ba9420c0), fd_no=20
> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG: <core>
[tcp_main.c:3515]:
> handle_tcp_child(): handle_tcp_child: CONN_RELEASE 0x7f21ba9420c0 refcnt= 1
>
> Cheers,
> Roberto Fichera.
>
>>
>> Cheers,
>> Daniel
>>
>> On 21/05/14 18:37, Roberto Fichera wrote:
>>> On 05/21/2014 09:08 AM, Roberto Fichera wrote:
>>>
>>> Hi There,
>>>
>>>> On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
>>>>> Hi Roberto,
>>>>
>>>> Hi Peter,
>>>>
>>>>> Did you ever figure out how to do it?
>>>>> I'd be interested too.
>>>>
>>>> Not yet! I tried other ways, barely workarounds, but I guess I'll
have to go into this
>>>> quite soon because it is the straight way to go. The main problem is the
lack of
>>>> my knowledge of kamailio API so I'll have to study a bit some code in
order to understand
>>>> how to use it.
>>>>
>>>> BTW the idea is to trigger an event route were I'd like to set all
the info regarding
>>>> the dispatched message including the result of the delivering. I
don't know if is possible
>>>> but the best would be to set all the pseudo-variables so that such event
route will be
>>>> in the right context of the given MSILO message.
>>>>
>>>> So, any advice regarding the API would definitively help and put me in
the right direction.
>>>
>>> Actually I've started to play with the above idea, so below you will find
my current implementation
>>> which seems executed because I see the LM_DBG() log but the code within the
event route but
>>> the corresponding script code does not.
>>>
>>> Any help?
>>>
>>> Cheers,
>>> Roberto Fichera.
>>>
>>>
>>> event_route [msilo:on-delivered] {
>>> xlog("L_INFO", "MSILO event on-delivered <$fu> to
<$ru>\n");
>>> }
>>>
>>>
>>> diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
>>> index 903b3cf..742c48d 100644
>>> --- a/modules/msilo/msilo.c
>>> +++ b/modules/msilo/msilo.c
>>> @@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
>>> return 0;
>>> }
>>>
>>> +/* where to go for the local request route ("msilo:on-delivered")
*/
>>> +int msilo_event_on_delivered=-1; /* default disabled */
>>> +
>>> /**
>>> * init module function
>>> */
>>> @@ -480,6 +483,11 @@ static int mod_init(void)
>>> if(ms_outbound_proxy.s!=NULL)
>>> ms_outbound_proxy.len = strlen(ms_outbound_proxy.s);
>>>
>>> + /* check if the on-delivered route event exists or not */
>>> + msilo_event_on_delivered=route_lookup(&event_rt,
"msilo:on-delivered");
>>> + if (msilo_event_on_delivered>=0 &&
event_rt.rlist[msilo_event_on_delivered]==0)
>>> + msilo_event_on_delivered=-1; /* disable */
>>> +
>>> return 0;
>>> }
>>>
>>> @@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t, int type, struct
tmcb_params *ps)
>>> LM_DBG("message <%d> was sent successfully\n",
*((int*)ps->param));
>>> msg_list_set_flag(ml, *((int*)ps->param), MS_MSG_DONE);
>>>
>>> + /* execute the msilo:on-delivered event route */
>>> + if(unlikely(msilo_event_on_delivered>=0))
>>> + {
>>> + int sflag_bk;
>>> + int backup_route_type;
>>> + struct run_act_ctx ctx;
>>> +
>>> + LM_DBG("executing event_route[msilo:on-delivered]
(%d)\n", msilo_event_on_delivered);
>>> +
>>> + sflag_bk = getsflags();
>>> + backup_route_type = get_route_type();
>>> +
>>> + set_route_type(EVENT_ROUTE);
>>> + init_run_actions_ctx(&ctx);
>>> + run_top_route(event_rt.rlist[msilo_event_on_delivered],
ps->req, &ctx);
>>> +
>>> + set_route_type(backup_route_type);
>>> + setsflagsval(sflag_bk);
>>> + }
>>> +
>>> done:
>>> return;
>>> }
>>>
>>>
>>>>
>>>> Cheers,
>>>> Roberto Fichera.
>>>>
>>>>>
>>>>> Cheers,
>>>>> Peter
>>>>>
>>>>>
>>>>> On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera
<kernel(a)tekno-soft.it <mailto:kernel@tekno-soft.it>> wrote:
>>>>>
>>>>> On 04/17/2014 10:36 AM, Roberto Fichera wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> > On 04/16/2014 07:15 PM, Roberto Fichera wrote:
>>>>> >
>>>>> > Hi All,
>>>>> >
>>>>> >> On 04/16/2014 06:53 PM, Daniel-Constantin Mierla wrote:
>>>>> >>> Hello,
>>>>> >> Ciao Daniel,
>>>>> >>
>>>>> >>> most likely the messages are looped back, be sure
you allow requests from 'myself' without authentication.
>>>>> >>>
>>>>> >>> You can watch loopback interface with ngrep to see
if the messages are sent out.
>>>>> >> Yep! Allowing requests from myself solved the problem!
Thanks!
>>>>> >>
>>>>> >> Another thing regarding MSILO, I would like to preserve
some custom header fields
>>>>> >> for both instant message and notification. How can I do
it?
>>>>> > I was able to solve this issue too, pretty straight I mean,
there is the extra_hdrs_avp param
>>>>> > which did the trick. BTW, is there a way to send back the
notification to the sender that
>>>>> > the message has been sent correctly via m_dump(), so to get
a 200 about the given
>>>>> > m_dump()ed message?
>>>>> >
>>>>>
>>>>> I think that this can be solved in a different way, the idea is
to add an event_route for the msilo
>>>>> module so that we get notified for each m_dump()ed message about
the given IM status and
>>>>> then handle it in the cfg file. So, looking at the code within
m_tm_callback() it seems that it's
>>>>> right place where to add such feature. Since I'm not a
kamailio developer but I've quite long
>>>>> time experience in C coding, does anyone can show/point me to
some example about
>>>>> how to do that?
>>>>>
>>>>> Thanks in advance,
>>>>> Roberto Fichera.
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
>>>>> sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
>>>>> sr-users(a)lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users(a)lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.com
>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:32 p.m.
On 05/26/2014 12:25 PM, Roberto Fichera wrote:
Ciao,
On 05/26/2014 12:17 PM, Daniel-Constantin Mierla
wrote:
Ciao,
Ah! No! Wait! The event route is executed within a tm callback via tmb.t_request() so
I'd expect a valid ps->req,
don't you think so?
Hello,
On 26/05/14 12:13, Roberto Fichera wrote:
Ok! Can you suggest the safest and reasonable way to setup the request for this case?
On 05/26/2014 12:03 PM, Daniel-Constantin Mierla
wrote:
that's the safe way. The event route is executed, but many functions that you can use
inside config routing blocks
require a non-null sip message structure. It is the case of xlog() for example, which
simply returns -1 if request is
null. Hello,
Ciao!
good that you sent a reminder -- I checked while offline traveling, but then forgot to
follow up.
I expect that ps->req is null in this case, because there is no request received by
kamailio. That results in xlog
not doing anything.
In other words, I expect the event route being executed, just the action inside is
doesn't do anything in this case.
Does this mean that I'll have to set a "faked" ps->req in order to get
the event route executed?
Cheers,
Roberto Fichera.
>
> Cheers, Daniel
>
>>
>> Cheers,
>> Roberto Fichera.
>>
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 26/05/14 11:40, Roberto Fichera wrote:
>>>> On 05/22/2014 09:08 AM, Roberto Fichera wrote:
>>>>> On 05/21/2014 11:15 PM, Daniel-Constantin Mierla wrote:
>>>>>> Hello,
>>>>
>>>> Ciao Daniel,
>>>>
>>>> have you had time to look at the problem below?
>>>>
>>>> Cheers,
>>>> Roberto Fichera.
>>>>
>>>>>
>>>>> Ciao,
>>>>>
>>>>>> can you send the log messages printed with debug=3?
>>>>>
>>>>> Yes! Sure! Here it is:
>>>>>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [receive.c:296]: receive_msg():
>>>>> receive_msg: cleaning up
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:633]:
>>>>> parse_msg(): SIP Reply (status):
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:635]:
>>>>> parse_msg(): version: <SIP/2.0>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:637]:
>>>>> parse_msg(): status: <202>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:639]:
>>>>> parse_msg(): reason: <Accepted>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]:
>>>>> parse_via_param(): Found param type 232, <branch> =
<z9hG4bK016e.a6c662d4000000000000000....0>; state=6
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]:
>>>>> parse_via_param(): Found param type 235, <rport> =
<1169>; state=6
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]:
>>>>> parse_via_param(): Found param type 234, <received> =
<xx.xx.xx.xx>; state=16
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:2672]:
>>>>> parse_via(): end of header reached, state=5
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:513]:
>>>>> parse_headers(): parse_headers: Via found, flags=2
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:515]:
>>>>> parse_headers(): parse_headers: this is the first via
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [receive.c:152]: receive_msg():
>>>>> After parse_msg...
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:1072]: t_check_msg(): DEBUG:
>>>>> t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_addr_spec.c:176]:
>>>>> parse_to_param(): DEBUG: add_param:
tag=74b38630e6be28bab2ebe17319971f33-c57e
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_addr_spec.c:893]:
>>>>> parse_addr_spec(): end of header reached, state=29
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:190]:
>>>>> get_hdr_field(): DEBUG: get_hdr_field: <To> [88];
uri=[sip:test1@test.com]
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:192]:
>>>>> get_hdr_field(): DEBUG: to body [<sip:test1@test.com>]
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:170]:
>>>>> get_hdr_field(): get_hdr_field: cseq <CSeq>: <10>
<MESSAGE>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:949]: t_reply_matching():
>>>>> DEBUG: t_reply_matching: hash 58896 label 0 branch 0
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:1004]: t_reply_matching():
>>>>> DEBUG: t_reply_matching: reply matched (T=0x7f21ba974408)!
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:1141]: t_check_msg(): DEBUG:
>>>>> t_check_msg: msg id=1 global id=1 T end=0x7f21ba974408
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:2206]: reply_received():
>>>>> DEBUG: reply_received: org. status uas=0, uac[0]=0 local=2
is_invite=0)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:1304]:
>>>>> t_should_relay_response(): ->>>>>>>>>
T_code=0, new_code=202
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:2086]: local_reply(): DEBUG:
>>>>> local_reply: branch=0, save=0, winner=0
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:2123]: local_reply(): DEBUG:
>>>>> local transaction completed
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_hooks.c:288]:
>>>>> run_trans_callbacks_internal(): DBG: trans=0x7f21ba974408, callback
type 1024, id 0 entered
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [msilo.c:1327]: m_tm_callback():
>>>>> completed with status 202 [mid: 139782841221704/4]
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [msilo.c:1340]: m_tm_callback():
>>>>> message <4> was sent successfully
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [ms_msg_list.c:236]:
>>>>> msg_list_set_flag(): mid:4 fl:4
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [msilo.c:1350]: m_tm_callback():
>>>>> executing event_route[msilo:on-delivered] (2)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:1663]: cleanup_uac_timers():
>>>>> DEBUG: cleanup_uac_timers: RETR/FR timers reset
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list():
>>>>> DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list():
>>>>> DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list():
>>>>> DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list():
>>>>> DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list():
>>>>> DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]: destroy_avp_list():
>>>>> DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [xavp.c:448]: xavp_destroy_list():
>>>>> destroying xavp list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [receive.c:296]: receive_msg():
>>>>> receive_msg: cleaning up
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [timer.c:77]: check_and_split_timer():
>>>>> splitting
0x7f21ba98dab0(0x7f21ba7b15f8,0x7f21ba7b15f8)node=0x7f21ba98daa0
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [timer.c:102]:
>>>>> check_and_split_timer(): succ. to split
(h=0x7f21ba7b15f8)(p=0x7f21ba7b15f8,n=0x7f21ba7b15f8)
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [pike_funcs.c:234]: clean_routine():
>>>>> clean node 0x7f21ba98daa0 (kids=(nil); hits=[0,0];leaf=[0,0])
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [pike_funcs.c:265]: clean_routine():
>>>>> rmv node 0x7f21ba98daa0[192]
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [ip_tree.c:364]: remove_node():
>>>>> destroying node 0x7f21ba98daa0
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [io_wait.h:617]: io_watch_del():
>>>>> DBG: io_watch_del (0x8eb2e0, 9, -1, 0x10) fd_no=2 called
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [tcp_read.c:1437]:
>>>>> release_tcpconn(): releasing con 0x7f21ba9420c0, state 1, fd=9, id=2
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [tcp_read.c:1438]:
>>>>> release_tcpconn(): extra_data 0x7f21ba941028
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [tcp_main.c:3385]:
>>>>> handle_tcp_child(): handle_tcp_child: reader response= 7f21ba9420c0,
1 from 2
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [io_wait.h:390]: io_watch_add():
>>>>> DBG: io_watch_add(0x893040, 28, 2, 0x7f21ba9420c0), fd_no=20
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [tcp_main.c:3515]:
>>>>> handle_tcp_child(): handle_tcp_child: CONN_RELEASE 0x7f21ba9420c0
refcnt= 1
>>>>>
>>>>> Cheers,
>>>>> Roberto Fichera.
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Daniel
>>>>>>
>>>>>> On 21/05/14 18:37, Roberto Fichera wrote:
>>>>>>> On 05/21/2014 09:08 AM, Roberto Fichera wrote:
>>>>>>>
>>>>>>> Hi There,
>>>>>>>
>>>>>>>> On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
>>>>>>>>> Hi Roberto,
>>>>>>>>
>>>>>>>> Hi Peter,
>>>>>>>>
>>>>>>>>> Did you ever figure out how to do it?
>>>>>>>>> I'd be interested too.
>>>>>>>>
>>>>>>>> Not yet! I tried other ways, barely workarounds, but I
guess I'll have to go into this
>>>>>>>> quite soon because it is the straight way to go. The main
problem is the lack of
>>>>>>>> my knowledge of kamailio API so I'll have to study a
bit some code in order to understand
>>>>>>>> how to use it.
>>>>>>>>
>>>>>>>> BTW the idea is to trigger an event route were I'd
like to set all the info regarding
>>>>>>>> the dispatched message including the result of the
delivering. I don't know if is possible
>>>>>>>> but the best would be to set all the pseudo-variables so
that such event route will be
>>>>>>>> in the right context of the given MSILO message.
>>>>>>>>
>>>>>>>> So, any advice regarding the API would definitively help
and put me in the right direction.
>>>>>>>
>>>>>>> Actually I've started to play with the above idea, so
below you will find my current implementation
>>>>>>> which seems executed because I see the LM_DBG() log but the
code within the event route but
>>>>>>> the corresponding script code does not.
>>>>>>>
>>>>>>> Any help?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Roberto Fichera.
>>>>>>>
>>>>>>>
>>>>>>> event_route [msilo:on-delivered] {
>>>>>>> xlog("L_INFO", "MSILO event on-delivered
<$fu> to <$ru>\n");
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
>>>>>>> index 903b3cf..742c48d 100644
>>>>>>> --- a/modules/msilo/msilo.c
>>>>>>> +++ b/modules/msilo/msilo.c
>>>>>>> @@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> +/* where to go for the local request route
("msilo:on-delivered") */
>>>>>>> +int msilo_event_on_delivered=-1; /* default disabled */
>>>>>>> +
>>>>>>> /**
>>>>>>> * init module function
>>>>>>> */
>>>>>>> @@ -480,6 +483,11 @@ static int mod_init(void)
>>>>>>> if(ms_outbound_proxy.s!=NULL)
>>>>>>> ms_outbound_proxy.len =
strlen(ms_outbound_proxy.s);
>>>>>>>
>>>>>>> + /* check if the on-delivered route event exists or
not */
>>>>>>> + msilo_event_on_delivered=route_lookup(&event_rt,
"msilo:on-delivered");
>>>>>>> + if (msilo_event_on_delivered>=0 &&
event_rt.rlist[msilo_event_on_delivered]==0)
>>>>>>> + msilo_event_on_delivered=-1; /* disable */
>>>>>>> +
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> @@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t,
int type, struct tmcb_params *ps)
>>>>>>> LM_DBG("message <%d> was sent
successfully\n", *((int*)ps->param));
>>>>>>> msg_list_set_flag(ml, *((int*)ps->param),
MS_MSG_DONE);
>>>>>>>
>>>>>>> + /* execute the msilo:on-delivered event route */
>>>>>>> + if(unlikely(msilo_event_on_delivered>=0))
>>>>>>> + {
>>>>>>> + int sflag_bk;
>>>>>>> + int backup_route_type;
>>>>>>> + struct run_act_ctx ctx;
>>>>>>> +
>>>>>>> + LM_DBG("executing
event_route[msilo:on-delivered] (%d)\n", msilo_event_on_delivered);
>>>>>>> +
>>>>>>> + sflag_bk = getsflags();
>>>>>>> + backup_route_type = get_route_type();
>>>>>>> +
>>>>>>> + set_route_type(EVENT_ROUTE);
>>>>>>> + init_run_actions_ctx(&ctx);
>>>>>>> +
run_top_route(event_rt.rlist[msilo_event_on_delivered], ps->req, &ctx);
>>>>>>> +
>>>>>>> + set_route_type(backup_route_type);
>>>>>>> + setsflagsval(sflag_bk);
>>>>>>> + }
>>>>>>> +
>>>>>>> done:
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Roberto Fichera.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera
<kernel(a)tekno-soft.it <mailto:kernel@tekno-soft.it>> wrote:
>>>>>>>>>
>>>>>>>>> On 04/17/2014 10:36 AM, Roberto Fichera wrote:
>>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> > On 04/16/2014 07:15 PM, Roberto Fichera
wrote:
>>>>>>>>> >
>>>>>>>>> > Hi All,
>>>>>>>>> >
>>>>>>>>> >> On 04/16/2014 06:53 PM,
Daniel-Constantin Mierla wrote:
>>>>>>>>> >>> Hello,
>>>>>>>>> >> Ciao Daniel,
>>>>>>>>> >>
>>>>>>>>> >>> most likely the messages are looped
back, be sure you allow requests from 'myself' without
>>>>>>>>> authentication.
>>>>>>>>> >>>
>>>>>>>>> >>> You can watch loopback interface
with ngrep to see if the messages are sent out.
>>>>>>>>> >> Yep! Allowing requests from myself
solved the problem! Thanks!
>>>>>>>>> >>
>>>>>>>>> >> Another thing regarding MSILO, I would
like to preserve some custom header fields
>>>>>>>>> >> for both instant message and
notification. How can I do it?
>>>>>>>>> > I was able to solve this issue too, pretty
straight I mean, there is the extra_hdrs_avp param
>>>>>>>>> > which did the trick. BTW, is there a way to
send back the notification to the sender that
>>>>>>>>> > the message has been sent correctly via
m_dump(), so to get a 200 about the given
>>>>>>>>> > m_dump()ed message?
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> I think that this can be solved in a different
way, the idea is to add an event_route for the msilo
>>>>>>>>> module so that we get notified for each
m_dump()ed message about the given IM status and
>>>>>>>>> then handle it in the cfg file. So, looking at
the code within m_tm_callback() it seems that it's
>>>>>>>>> right place where to add such feature. Since
I'm not a kamailio developer but I've quite long
>>>>>>>>> time experience in C coding, does anyone can
show/point me to some example about
>>>>>>>>> how to do that?
>>>>>>>>>
>>>>>>>>> Thanks in advance,
>>>>>>>>> Roberto Fichera.
>>>>>>>>>
2:04 p.m.
On 05/26/2014 12:32 PM, Roberto Fichera wrote:
Ciao,
On 05/26/2014 12:25 PM, Roberto Fichera wrote:
Ciao,
I've found how to change the code ... just testing the logic. I'll get back to you
in case.
Cheer,
Roberto Fichera.
On 05/26/2014 12:17 PM, Daniel-Constantin Mierla
wrote:
Ciao,
Ah! No! Wait! The event route is executed within a tm callback via tmb.t_request() so
I'd expect a valid ps->req,
don't you think so? Hello,
On 26/05/14 12:13, Roberto Fichera wrote:
Ok! Can you suggest the safest and reasonable way to setup the request for this case?
On 05/26/2014 12:03 PM, Daniel-Constantin Mierla
wrote:
> Hello,
Ciao!
>
> good that you sent a reminder -- I checked while offline traveling, but then forgot
to follow up.
>
> I expect that ps->req is null in this case, because there is no request received
by kamailio. That results in xlog
> not doing anything.
>
> In other words, I expect the event route being executed, just the action inside is
doesn't do anything in this case.
Does this mean that I'll have to set a "faked" ps->req in order to get
the event route executed?
that's the safe way. The event route is executed, but many functions that you can use
inside config routing blocks
require a non-null sip message structure. It is the case of xlog() for example, which
simply returns -1 if request
is null.
Cheers,
Roberto Fichera.
>
> Cheers, Daniel
>
>>
>> Cheers,
>> Roberto Fichera.
>>
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 26/05/14 11:40, Roberto Fichera wrote:
>>>> On 05/22/2014 09:08 AM, Roberto Fichera wrote:
>>>>> On 05/21/2014 11:15 PM, Daniel-Constantin Mierla wrote:
>>>>>> Hello,
>>>>
>>>> Ciao Daniel,
>>>>
>>>> have you had time to look at the problem below?
>>>>
>>>> Cheers,
>>>> Roberto Fichera.
>>>>
>>>>>
>>>>> Ciao,
>>>>>
>>>>>> can you send the log messages printed with debug=3?
>>>>>
>>>>> Yes! Sure! Here it is:
>>>>>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [receive.c:296]: receive_msg():
>>>>> receive_msg: cleaning up
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:633]:
>>>>> parse_msg(): SIP Reply (status):
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:635]:
>>>>> parse_msg(): version: <SIP/2.0>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:637]:
>>>>> parse_msg(): status: <202>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:639]:
>>>>> parse_msg(): reason: <Accepted>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]:
>>>>> parse_via_param(): Found param type 232, <branch> =
<z9hG4bK016e.a6c662d4000000000000000....0>; state=6
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]:
>>>>> parse_via_param(): Found param type 235, <rport> =
<1169>; state=6
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]:
>>>>> parse_via_param(): Found param type 234, <received> =
<xx.xx.xx.xx>; state=16
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:2672]:
>>>>> parse_via(): end of header reached, state=5
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:513]:
>>>>> parse_headers(): parse_headers: Via found, flags=2
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:515]:
>>>>> parse_headers(): parse_headers: this is the first via
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [receive.c:152]: receive_msg():
>>>>> After parse_msg...
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:1072]: t_check_msg():
>>>>> DEBUG: t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_addr_spec.c:176]:
>>>>> parse_to_param(): DEBUG: add_param:
tag=74b38630e6be28bab2ebe17319971f33-c57e
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_addr_spec.c:893]:
>>>>> parse_addr_spec(): end of header reached, state=29
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:190]:
>>>>> get_hdr_field(): DEBUG: get_hdr_field: <To> [88];
uri=[sip:test1@test.com]
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:192]:
>>>>> get_hdr_field(): DEBUG: to body [<sip:test1@test.com>]
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:170]:
>>>>> get_hdr_field(): get_hdr_field: cseq <CSeq>: <10>
<MESSAGE>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:949]: t_reply_matching():
>>>>> DEBUG: t_reply_matching: hash 58896 label 0 branch 0
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:1004]: t_reply_matching():
>>>>> DEBUG: t_reply_matching: reply matched (T=0x7f21ba974408)!
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:1141]: t_check_msg():
>>>>> DEBUG: t_check_msg: msg id=1 global id=1 T end=0x7f21ba974408
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:2206]: reply_received():
>>>>> DEBUG: reply_received: org. status uas=0, uac[0]=0 local=2
is_invite=0)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:1304]:
>>>>> t_should_relay_response(): ->>>>>>>>>
T_code=0, new_code=202
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:2086]: local_reply(): DEBUG:
>>>>> local_reply: branch=0, save=0, winner=0
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:2123]: local_reply(): DEBUG:
>>>>> local transaction completed
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_hooks.c:288]:
>>>>> run_trans_callbacks_internal(): DBG: trans=0x7f21ba974408, callback
type 1024, id 0 entered
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [msilo.c:1327]: m_tm_callback():
>>>>> completed with status 202 [mid: 139782841221704/4]
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [msilo.c:1340]: m_tm_callback():
>>>>> message <4> was sent successfully
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [ms_msg_list.c:236]:
>>>>> msg_list_set_flag(): mid:4 fl:4
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [msilo.c:1350]: m_tm_callback():
>>>>> executing event_route[msilo:on-delivered] (2)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:1663]: cleanup_uac_timers():
>>>>> DEBUG: cleanup_uac_timers: RETR/FR timers reset
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]:
>>>>> destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]:
>>>>> destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]:
>>>>> destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]:
>>>>> destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]:
>>>>> destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]:
>>>>> destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [xavp.c:448]: xavp_destroy_list():
>>>>> destroying xavp list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [receive.c:296]: receive_msg():
>>>>> receive_msg: cleaning up
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [timer.c:77]:
>>>>> check_and_split_timer(): splitting
0x7f21ba98dab0(0x7f21ba7b15f8,0x7f21ba7b15f8)node=0x7f21ba98daa0
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [timer.c:102]:
>>>>> check_and_split_timer(): succ. to split
(h=0x7f21ba7b15f8)(p=0x7f21ba7b15f8,n=0x7f21ba7b15f8)
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [pike_funcs.c:234]: clean_routine():
>>>>> clean node 0x7f21ba98daa0 (kids=(nil); hits=[0,0];leaf=[0,0])
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [pike_funcs.c:265]: clean_routine():
>>>>> rmv node 0x7f21ba98daa0[192]
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [ip_tree.c:364]: remove_node():
>>>>> destroying node 0x7f21ba98daa0
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [io_wait.h:617]: io_watch_del():
>>>>> DBG: io_watch_del (0x8eb2e0, 9, -1, 0x10) fd_no=2 called
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [tcp_read.c:1437]:
>>>>> release_tcpconn(): releasing con 0x7f21ba9420c0, state 1, fd=9, id=2
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [tcp_read.c:1438]:
>>>>> release_tcpconn(): extra_data 0x7f21ba941028
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [tcp_main.c:3385]:
>>>>> handle_tcp_child(): handle_tcp_child: reader response= 7f21ba9420c0,
1 from 2
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [io_wait.h:390]: io_watch_add():
>>>>> DBG: io_watch_add(0x893040, 28, 2, 0x7f21ba9420c0), fd_no=20
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [tcp_main.c:3515]:
>>>>> handle_tcp_child(): handle_tcp_child: CONN_RELEASE 0x7f21ba9420c0
refcnt= 1
>>>>>
>>>>> Cheers,
>>>>> Roberto Fichera.
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Daniel
>>>>>>
>>>>>> On 21/05/14 18:37, Roberto Fichera wrote:
>>>>>>> On 05/21/2014 09:08 AM, Roberto Fichera wrote:
>>>>>>>
>>>>>>> Hi There,
>>>>>>>
>>>>>>>> On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
>>>>>>>>> Hi Roberto,
>>>>>>>>
>>>>>>>> Hi Peter,
>>>>>>>>
>>>>>>>>> Did you ever figure out how to do it?
>>>>>>>>> I'd be interested too.
>>>>>>>>
>>>>>>>> Not yet! I tried other ways, barely workarounds, but I
guess I'll have to go into this
>>>>>>>> quite soon because it is the straight way to go. The main
problem is the lack of
>>>>>>>> my knowledge of kamailio API so I'll have to study a
bit some code in order to understand
>>>>>>>> how to use it.
>>>>>>>>
>>>>>>>> BTW the idea is to trigger an event route were I'd
like to set all the info regarding
>>>>>>>> the dispatched message including the result of the
delivering. I don't know if is possible
>>>>>>>> but the best would be to set all the pseudo-variables so
that such event route will be
>>>>>>>> in the right context of the given MSILO message.
>>>>>>>>
>>>>>>>> So, any advice regarding the API would definitively help
and put me in the right direction.
>>>>>>>
>>>>>>> Actually I've started to play with the above idea, so
below you will find my current implementation
>>>>>>> which seems executed because I see the LM_DBG() log but the
code within the event route but
>>>>>>> the corresponding script code does not.
>>>>>>>
>>>>>>> Any help?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Roberto Fichera.
>>>>>>>
>>>>>>>
>>>>>>> event_route [msilo:on-delivered] {
>>>>>>> xlog("L_INFO", "MSILO event on-delivered
<$fu> to <$ru>\n");
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
>>>>>>> index 903b3cf..742c48d 100644
>>>>>>> --- a/modules/msilo/msilo.c
>>>>>>> +++ b/modules/msilo/msilo.c
>>>>>>> @@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> +/* where to go for the local request route
("msilo:on-delivered") */
>>>>>>> +int msilo_event_on_delivered=-1; /* default disabled */
>>>>>>> +
>>>>>>> /**
>>>>>>> * init module function
>>>>>>> */
>>>>>>> @@ -480,6 +483,11 @@ static int mod_init(void)
>>>>>>> if(ms_outbound_proxy.s!=NULL)
>>>>>>> ms_outbound_proxy.len =
strlen(ms_outbound_proxy.s);
>>>>>>>
>>>>>>> + /* check if the on-delivered route event exists or
not */
>>>>>>> + msilo_event_on_delivered=route_lookup(&event_rt,
"msilo:on-delivered");
>>>>>>> + if (msilo_event_on_delivered>=0 &&
event_rt.rlist[msilo_event_on_delivered]==0)
>>>>>>> + msilo_event_on_delivered=-1; /* disable */
>>>>>>> +
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> @@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t,
int type, struct tmcb_params *ps)
>>>>>>> LM_DBG("message <%d> was sent
successfully\n", *((int*)ps->param));
>>>>>>> msg_list_set_flag(ml, *((int*)ps->param),
MS_MSG_DONE);
>>>>>>>
>>>>>>> + /* execute the msilo:on-delivered event route */
>>>>>>> + if(unlikely(msilo_event_on_delivered>=0))
>>>>>>> + {
>>>>>>> + int sflag_bk;
>>>>>>> + int backup_route_type;
>>>>>>> + struct run_act_ctx ctx;
>>>>>>> +
>>>>>>> + LM_DBG("executing
event_route[msilo:on-delivered] (%d)\n", msilo_event_on_delivered);
>>>>>>> +
>>>>>>> + sflag_bk = getsflags();
>>>>>>> + backup_route_type = get_route_type();
>>>>>>> +
>>>>>>> + set_route_type(EVENT_ROUTE);
>>>>>>> + init_run_actions_ctx(&ctx);
>>>>>>> +
run_top_route(event_rt.rlist[msilo_event_on_delivered], ps->req, &ctx);
>>>>>>> +
>>>>>>> + set_route_type(backup_route_type);
>>>>>>> + setsflagsval(sflag_bk);
>>>>>>> + }
>>>>>>> +
>>>>>>> done:
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Roberto Fichera.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera
<kernel(a)tekno-soft.it <mailto:kernel@tekno-soft.it>> wrote:
>>>>>>>>>
>>>>>>>>> On 04/17/2014 10:36 AM, Roberto Fichera wrote:
>>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> > On 04/16/2014 07:15 PM, Roberto Fichera
wrote:
>>>>>>>>> >
>>>>>>>>> > Hi All,
>>>>>>>>> >
>>>>>>>>> >> On 04/16/2014 06:53 PM,
Daniel-Constantin Mierla wrote:
>>>>>>>>> >>> Hello,
>>>>>>>>> >> Ciao Daniel,
>>>>>>>>> >>
>>>>>>>>> >>> most likely the messages are looped
back, be sure you allow requests from 'myself' without
>>>>>>>>> authentication.
>>>>>>>>> >>>
>>>>>>>>> >>> You can watch loopback interface
with ngrep to see if the messages are sent out.
>>>>>>>>> >> Yep! Allowing requests from myself
solved the problem! Thanks!
>>>>>>>>> >>
>>>>>>>>> >> Another thing regarding MSILO, I would
like to preserve some custom header fields
>>>>>>>>> >> for both instant message and
notification. How can I do it?
>>>>>>>>> > I was able to solve this issue too, pretty
straight I mean, there is the extra_hdrs_avp param
>>>>>>>>> > which did the trick. BTW, is there a way to
send back the notification to the sender that
>>>>>>>>> > the message has been sent correctly via
m_dump(), so to get a 200 about the given
>>>>>>>>> > m_dump()ed message?
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> I think that this can be solved in a different
way, the idea is to add an event_route for the msilo
>>>>>>>>> module so that we get notified for each
m_dump()ed message about the given IM status and
>>>>>>>>> then handle it in the cfg file. So, looking at
the code within m_tm_callback() it seems that it's
>>>>>>>>> right place where to add such feature. Since
I'm not a kamailio developer but I've quite long
>>>>>>>>> time experience in C coding, does anyone can
show/point me to some example about
>>>>>>>>> how to do that?
>>>>>>>>>
>>>>>>>>> Thanks in advance,
>>>>>>>>> Roberto Fichera.
>>>>>>>>>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:46 p.m.
On 05/26/2014 01:04 PM, Roberto Fichera wrote:
Ciao,
[...]
Ah! No! Wait! The event route is executed within a tm callback via tmb.t_request() so
I'd expect a valid ps->req,
don't you think so?
I've found how to change the code ... just testing the logic. I'll get back to
you in case.
After a while I've found that I can pass a request using the uac_r.cbp field, so
I've fixed the callback
to use the passed fields instead a straight int (previously mid==message id) but I'm
not sure how to
build a fake sip_msg request regarding the given msilo dumped msg, could you please give
me a
tips how to do so?
Cheers,
Roberto Fichera.
On 26/05/14 12:13, Roberto Fichera wrote:
> On 05/26/2014 12:03 PM, Daniel-Constantin Mierla wrote:
>> Hello,
>
> Ciao!
>
>>
>> good that you sent a reminder -- I checked while offline traveling, but then
forgot to follow up.
>>
>> I expect that ps->req is null in this case, because there is no request
received by kamailio. That results in
>> xlog not doing anything.
>>
>> In other words, I expect the event route being executed, just the action inside
is doesn't do anything in this case.
>
> Does this mean that I'll have to set a "faked" ps->req in order to
get the event route executed?
that's the safe way. The event route is executed, but many functions that you can use
inside config routing blocks
require a non-null sip message structure. It is the case of xlog() for example, which
simply returns -1 if request
is null.
Ok! Can you suggest the safest and reasonable way to setup the request for this case?
Cheer,
Roberto Fichera.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Cheers,
Roberto Fichera.
>
> Cheers, Daniel
>
>>
>> Cheers,
>> Roberto Fichera.
>>
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 26/05/14 11:40, Roberto Fichera wrote:
>>>> On 05/22/2014 09:08 AM, Roberto Fichera wrote:
>>>>> On 05/21/2014 11:15 PM, Daniel-Constantin Mierla wrote:
>>>>>> Hello,
>>>>
>>>> Ciao Daniel,
>>>>
>>>> have you had time to look at the problem below?
>>>>
>>>> Cheers,
>>>> Roberto Fichera.
>>>>
>>>>>
>>>>> Ciao,
>>>>>
>>>>>> can you send the log messages printed with debug=3?
>>>>>
>>>>> Yes! Sure! Here it is:
>>>>>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [receive.c:296]: receive_msg():
>>>>> receive_msg: cleaning up
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:633]:
>>>>> parse_msg(): SIP Reply (status):
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:635]:
>>>>> parse_msg(): version: <SIP/2.0>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:637]:
>>>>> parse_msg(): status: <202>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:639]:
>>>>> parse_msg(): reason: <Accepted>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]:
>>>>> parse_via_param(): Found param type 232, <branch> =
<z9hG4bK016e.a6c662d4000000000000000....0>; state=6
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]:
>>>>> parse_via_param(): Found param type 235, <rport> =
<1169>; state=6
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:1284]:
>>>>> parse_via_param(): Found param type 234, <received> =
<xx.xx.xx.xx>; state=16
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_via.c:2672]:
>>>>> parse_via(): end of header reached, state=5
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:513]:
>>>>> parse_headers(): parse_headers: Via found, flags=2
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:515]:
>>>>> parse_headers(): parse_headers: this is the first via
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [receive.c:152]: receive_msg():
>>>>> After parse_msg...
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:1072]: t_check_msg():
>>>>> DEBUG: t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_addr_spec.c:176]:
>>>>> parse_to_param(): DEBUG: add_param:
tag=74b38630e6be28bab2ebe17319971f33-c57e
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/parse_addr_spec.c:893]:
>>>>> parse_addr_spec(): end of header reached, state=29
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:190]:
>>>>> get_hdr_field(): DEBUG: get_hdr_field: <To> [88];
uri=[sip:test1@test.com]
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:192]:
>>>>> get_hdr_field(): DEBUG: to body [<sip:test1@test.com>]
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [parser/msg_parser.c:170]:
>>>>> get_hdr_field(): get_hdr_field: cseq <CSeq>: <10>
<MESSAGE>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:949]: t_reply_matching():
>>>>> DEBUG: t_reply_matching: hash 58896 label 0 branch 0
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:1004]: t_reply_matching():
>>>>> DEBUG: t_reply_matching: reply matched (T=0x7f21ba974408)!
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_lookup.c:1141]: t_check_msg():
>>>>> DEBUG: t_check_msg: msg id=1 global id=1 T end=0x7f21ba974408
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:2206]: reply_received():
>>>>> DEBUG: reply_received: org. status uas=0, uac[0]=0 local=2
is_invite=0)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:1304]:
>>>>> t_should_relay_response(): ->>>>>>>>>
T_code=0, new_code=202
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:2086]: local_reply():
>>>>> DEBUG: local_reply: branch=0, save=0, winner=0
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:2123]: local_reply():
>>>>> DEBUG: local transaction completed
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_hooks.c:288]:
>>>>> run_trans_callbacks_internal(): DBG: trans=0x7f21ba974408, callback
type 1024, id 0 entered
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [msilo.c:1327]: m_tm_callback():
>>>>> completed with status 202 [mid: 139782841221704/4]
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [msilo.c:1340]: m_tm_callback():
>>>>> message <4> was sent successfully
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [ms_msg_list.c:236]:
>>>>> msg_list_set_flag(): mid:4 fl:4
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
msilo [msilo.c:1350]: m_tm_callback():
>>>>> executing event_route[msilo:on-delivered] (2)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
tm [t_reply.c:1663]:
>>>>> cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers
reset
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]:
>>>>> destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]:
>>>>> destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]:
>>>>> destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]:
>>>>> destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]:
>>>>> destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [usr_avp.c:644]:
>>>>> destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [xavp.c:448]: xavp_destroy_list():
>>>>> destroying xavp list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]: DEBUG:
<core> [receive.c:296]: receive_msg():
>>>>> receive_msg: cleaning up
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [timer.c:77]:
>>>>> check_and_split_timer(): splitting
0x7f21ba98dab0(0x7f21ba7b15f8,0x7f21ba7b15f8)node=0x7f21ba98daa0
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [timer.c:102]:
>>>>> check_and_split_timer(): succ. to split
(h=0x7f21ba7b15f8)(p=0x7f21ba7b15f8,n=0x7f21ba7b15f8)
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [pike_funcs.c:234]: clean_routine():
>>>>> clean node 0x7f21ba98daa0 (kids=(nil); hits=[0,0];leaf=[0,0])
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [pike_funcs.c:265]: clean_routine():
>>>>> rmv node 0x7f21ba98daa0[192]
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]: DEBUG:
pike [ip_tree.c:364]: remove_node():
>>>>> destroying node 0x7f21ba98daa0
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [io_wait.h:617]: io_watch_del():
>>>>> DBG: io_watch_del (0x8eb2e0, 9, -1, 0x10) fd_no=2 called
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [tcp_read.c:1437]:
>>>>> release_tcpconn(): releasing con 0x7f21ba9420c0, state 1, fd=9, id=2
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]: DEBUG:
<core> [tcp_read.c:1438]:
>>>>> release_tcpconn(): extra_data 0x7f21ba941028
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [tcp_main.c:3385]:
>>>>> handle_tcp_child(): handle_tcp_child: reader response= 7f21ba9420c0,
1 from 2
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [io_wait.h:390]: io_watch_add():
>>>>> DBG: io_watch_add(0x893040, 28, 2, 0x7f21ba9420c0), fd_no=20
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]: DEBUG:
<core> [tcp_main.c:3515]:
>>>>> handle_tcp_child(): handle_tcp_child: CONN_RELEASE 0x7f21ba9420c0
refcnt= 1
>>>>>
>>>>> Cheers,
>>>>> Roberto Fichera.
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Daniel
>>>>>>
>>>>>> On 21/05/14 18:37, Roberto Fichera wrote:
>>>>>>> On 05/21/2014 09:08 AM, Roberto Fichera wrote:
>>>>>>>
>>>>>>> Hi There,
>>>>>>>
>>>>>>>> On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
>>>>>>>>> Hi Roberto,
>>>>>>>>
>>>>>>>> Hi Peter,
>>>>>>>>
>>>>>>>>> Did you ever figure out how to do it?
>>>>>>>>> I'd be interested too.
>>>>>>>>
>>>>>>>> Not yet! I tried other ways, barely workarounds, but I
guess I'll have to go into this
>>>>>>>> quite soon because it is the straight way to go. The main
problem is the lack of
>>>>>>>> my knowledge of kamailio API so I'll have to study a
bit some code in order to understand
>>>>>>>> how to use it.
>>>>>>>>
>>>>>>>> BTW the idea is to trigger an event route were I'd
like to set all the info regarding
>>>>>>>> the dispatched message including the result of the
delivering. I don't know if is possible
>>>>>>>> but the best would be to set all the pseudo-variables so
that such event route will be
>>>>>>>> in the right context of the given MSILO message.
>>>>>>>>
>>>>>>>> So, any advice regarding the API would definitively help
and put me in the right direction.
>>>>>>>
>>>>>>> Actually I've started to play with the above idea, so
below you will find my current implementation
>>>>>>> which seems executed because I see the LM_DBG() log but the
code within the event route but
>>>>>>> the corresponding script code does not.
>>>>>>>
>>>>>>> Any help?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Roberto Fichera.
>>>>>>>
>>>>>>>
>>>>>>> event_route [msilo:on-delivered] {
>>>>>>> xlog("L_INFO", "MSILO event on-delivered
<$fu> to <$ru>\n");
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
>>>>>>> index 903b3cf..742c48d 100644
>>>>>>> --- a/modules/msilo/msilo.c
>>>>>>> +++ b/modules/msilo/msilo.c
>>>>>>> @@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> +/* where to go for the local request route
("msilo:on-delivered") */
>>>>>>> +int msilo_event_on_delivered=-1; /* default disabled */
>>>>>>> +
>>>>>>> /**
>>>>>>> * init module function
>>>>>>> */
>>>>>>> @@ -480,6 +483,11 @@ static int mod_init(void)
>>>>>>> if(ms_outbound_proxy.s!=NULL)
>>>>>>> ms_outbound_proxy.len =
strlen(ms_outbound_proxy.s);
>>>>>>>
>>>>>>> + /* check if the on-delivered route event exists or
not */
>>>>>>> + msilo_event_on_delivered=route_lookup(&event_rt,
"msilo:on-delivered");
>>>>>>> + if (msilo_event_on_delivered>=0 &&
event_rt.rlist[msilo_event_on_delivered]==0)
>>>>>>> + msilo_event_on_delivered=-1; /* disable */
>>>>>>> +
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> @@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t,
int type, struct tmcb_params *ps)
>>>>>>> LM_DBG("message <%d> was sent
successfully\n", *((int*)ps->param));
>>>>>>> msg_list_set_flag(ml, *((int*)ps->param),
MS_MSG_DONE);
>>>>>>>
>>>>>>> + /* execute the msilo:on-delivered event route */
>>>>>>> + if(unlikely(msilo_event_on_delivered>=0))
>>>>>>> + {
>>>>>>> + int sflag_bk;
>>>>>>> + int backup_route_type;
>>>>>>> + struct run_act_ctx ctx;
>>>>>>> +
>>>>>>> + LM_DBG("executing
event_route[msilo:on-delivered] (%d)\n", msilo_event_on_delivered);
>>>>>>> +
>>>>>>> + sflag_bk = getsflags();
>>>>>>> + backup_route_type = get_route_type();
>>>>>>> +
>>>>>>> + set_route_type(EVENT_ROUTE);
>>>>>>> + init_run_actions_ctx(&ctx);
>>>>>>> +
run_top_route(event_rt.rlist[msilo_event_on_delivered], ps->req, &ctx);
>>>>>>> +
>>>>>>> + set_route_type(backup_route_type);
>>>>>>> + setsflagsval(sflag_bk);
>>>>>>> + }
>>>>>>> +
>>>>>>> done:
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Roberto Fichera.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera
<kernel(a)tekno-soft.it <mailto:kernel@tekno-soft.it>> wrote:
>>>>>>>>>
>>>>>>>>> On 04/17/2014 10:36 AM, Roberto Fichera wrote:
>>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> > On 04/16/2014 07:15 PM, Roberto Fichera
wrote:
>>>>>>>>> >
>>>>>>>>> > Hi All,
>>>>>>>>> >
>>>>>>>>> >> On 04/16/2014 06:53 PM,
Daniel-Constantin Mierla wrote:
>>>>>>>>> >>> Hello,
>>>>>>>>> >> Ciao Daniel,
>>>>>>>>> >>
>>>>>>>>> >>> most likely the messages are looped
back, be sure you allow requests from 'myself' without
>>>>>>>>> authentication.
>>>>>>>>> >>>
>>>>>>>>> >>> You can watch loopback interface
with ngrep to see if the messages are sent out.
>>>>>>>>> >> Yep! Allowing requests from myself
solved the problem! Thanks!
>>>>>>>>> >>
>>>>>>>>> >> Another thing regarding MSILO, I would
like to preserve some custom header fields
>>>>>>>>> >> for both instant message and
notification. How can I do it?
>>>>>>>>> > I was able to solve this issue too, pretty
straight I mean, there is the extra_hdrs_avp param
>>>>>>>>> > which did the trick. BTW, is there a way to
send back the notification to the sender that
>>>>>>>>> > the message has been sent correctly via
m_dump(), so to get a 200 about the given
>>>>>>>>> > m_dump()ed message?
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> I think that this can be solved in a different
way, the idea is to add an event_route for the msilo
>>>>>>>>> module so that we get notified for each
m_dump()ed message about the given IM status and
>>>>>>>>> then handle it in the cfg file. So, looking at
the code within m_tm_callback() it seems that it's
>>>>>>>>> right place where to add such feature. Since
I'm not a kamailio developer but I've quite long
>>>>>>>>> time experience in C coding, does anyone can
show/point me to some example about
>>>>>>>>> how to do that?
>>>>>>>>>
>>>>>>>>> Thanks in advance,
>>>>>>>>> Roberto Fichera.
>>>>>>>>>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
27 May
27 May
9:37 a.m.
Hello,
you can re-use the lib/kcore/faked_msg.{c,h} in your code, same being
done by many event routes. Alternative is to build it yourself from the
outgoing buffer, which is in transaction structure, inside the uac field
(see tm_cell_t structure).
Easier might be to run this event route with the response sip msg
structure -- if you run it only when 200ok is received, the callback
from tm has the response structure.
Cheers,
Daniel
On 26/05/14 16:46, Roberto Fichera wrote:
On 05/26/2014 01:04 PM, Roberto Fichera wrote:
Ciao,
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
[...]
I've found how to change the code ... just testing the logic. I'll
get back to you in case.
After a while I've found that I can pass a request using the uac_r.cbp
field, so I've fixed the callback
to use the passed fields instead a straight int (previously
mid==message id) but I'm not sure how to
build a fake sip_msg request regarding the given msilo dumped msg,
could you please give me a
tips how to do so?
Cheers,
Roberto Fichera.
>
> On 26/05/14 12:13, Roberto Fichera wrote:
>> On 05/26/2014 12:03 PM, Daniel-Constantin Mierla wrote:
>>> Hello,
>>
>> Ciao!
>>
>>>
>>> good that you sent a reminder -- I checked while offline
>>> traveling, but then forgot to follow up.
>>>
>>> I expect that ps->req is null in this case, because there is no
>>> request received by kamailio. That results in xlog not doing
>>> anything.
>>>
>>> In other words, I expect the event route being executed, just
>>> the action inside is doesn't do anything in this case.
>>
>> Does this mean that I'll have to set a "faked" ps->req in order
>> to get the event route executed?
>
> that's the safe way. The event route is executed, but many
> functions that you can use inside config routing blocks require a
> non-null sip message structure. It is the case of xlog() for
> example, which simply returns -1 if request is null.
Ok! Can you suggest the safest and reasonable way to setup the
request for this case?
Ah! No! Wait! The event route is executed within a tm callback via
tmb.t_request() so I'd expect a valid ps->req,
don't you think so?
Cheer,
Roberto Fichera.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Cheers,
Roberto Fichera.
>
> Cheers, Daniel
>
>>
>> Cheers,
>> Roberto Fichera.
>>
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 26/05/14 11:40, Roberto Fichera wrote:
>>>> On 05/22/2014 09:08 AM, Roberto Fichera wrote:
>>>>> On 05/21/2014 11:15 PM, Daniel-Constantin Mierla wrote:
>>>>>> Hello,
>>>>
>>>> Ciao Daniel,
>>>>
>>>> have you had time to look at the problem below?
>>>>
>>>> Cheers,
>>>> Roberto Fichera.
>>>>
>>>>>
>>>>> Ciao,
>>>>>
>>>>>> can you send the log messages printed with debug=3?
>>>>>
>>>>> Yes! Sure! Here it is:
>>>>>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8454]:
>>>>> DEBUG: <core> [receive.c:296]: receive_msg(): receive_msg:
>>>>> cleaning up
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/msg_parser.c:633]: parse_msg(): SIP
>>>>> Reply (status):
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/msg_parser.c:635]: parse_msg():
>>>>> version: <SIP/2.0>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/msg_parser.c:637]: parse_msg(): status:
>>>>> <202>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/msg_parser.c:639]: parse_msg(): reason:
>>>>> <Accepted>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param():
>>>>> Found param type 232, <branch> =
>>>>> <z9hG4bK016e.a6c662d4000000000000000....0>; state=6
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param():
>>>>> Found param type 235, <rport> = <1169>; state=6
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param():
>>>>> Found param type 234, <received> = <xx.xx.xx.xx>;
state=16
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of
>>>>> header reached, state=5
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/msg_parser.c:513]: parse_headers():
>>>>> parse_headers: Via found, flags=2
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/msg_parser.c:515]: parse_headers():
>>>>> parse_headers: this is the first via
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [receive.c:152]: receive_msg(): After
parse_msg...
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG:
>>>>> t_check_msg: msg id=1 global id=0 T start=0xffffffffffffffff
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/parse_addr_spec.c:176]:
>>>>> parse_to_param(): DEBUG: add_param:
>>>>> tag=74b38630e6be28bab2ebe17319971f33-c57e
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/parse_addr_spec.c:893]:
>>>>> parse_addr_spec(): end of header reached, state=29
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field():
>>>>> DEBUG: get_hdr_field: <To> [88]; uri=[sip:test1@test.com]
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field():
>>>>> DEBUG: to body [<sip:test1@test.com>]
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field():
>>>>> get_hdr_field: cseq <CSeq>: <10> <MESSAGE>
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG:
>>>>> t_reply_matching: hash 58896 label 0 branch 0
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: tm [t_lookup.c:1004]: t_reply_matching(): DEBUG:
>>>>> t_reply_matching: reply matched (T=0x7f21ba974408)!
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG:
>>>>> t_check_msg: msg id=1 global id=1 T end=0x7f21ba974408
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: tm [t_reply.c:2206]: reply_received(): DEBUG:
>>>>> reply_received: org. status uas=0, uac[0]=0 local=2 is_invite=0)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: tm [t_reply.c:1304]: t_should_relay_response():
>>>>> ->>>>>>>>> T_code=0, new_code=202
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: tm [t_reply.c:2086]: local_reply(): DEBUG: local_reply:
>>>>> branch=0, save=0, winner=0
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: tm [t_reply.c:2123]: local_reply(): DEBUG: local
>>>>> transaction completed
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal():
>>>>> DBG: trans=0x7f21ba974408, callback type 1024, id 0 entered
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: msilo [msilo.c:1327]: m_tm_callback(): completed with
>>>>> status 202 [mid: 139782841221704/4]
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: msilo [msilo.c:1340]: m_tm_callback(): message <4> was
>>>>> sent successfully
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: msilo [ms_msg_list.c:236]: msg_list_set_flag(): mid:4 fl:4
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: msilo [msilo.c:1350]: m_tm_callback(): executing
>>>>> event_route[msilo:on-delivered] (2)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: tm [t_reply.c:1663]: cleanup_uac_timers(): DEBUG:
>>>>> cleanup_uac_timers: RETR/FR timers reset
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [usr_avp.c:644]: destroy_avp_list():
>>>>> DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [usr_avp.c:644]: destroy_avp_list():
>>>>> DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [usr_avp.c:644]: destroy_avp_list():
>>>>> DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [usr_avp.c:644]: destroy_avp_list():
>>>>> DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [usr_avp.c:644]: destroy_avp_list():
>>>>> DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [usr_avp.c:644]: destroy_avp_list():
>>>>> DEBUG:destroy_avp_list: destroying list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying
>>>>> xavp list (nil)
>>>>> May 22 08:58:04 dragon.tekno-soft.it /usr/sbin/kamailio[8436]:
>>>>> DEBUG: <core> [receive.c:296]: receive_msg(): receive_msg:
>>>>> cleaning up
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]:
>>>>> DEBUG: pike [timer.c:77]: check_and_split_timer(): splitting
>>>>> 0x7f21ba98dab0(0x7f21ba7b15f8,0x7f21ba7b15f8)node=0x7f21ba98daa0
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]:
>>>>> DEBUG: pike [timer.c:102]: check_and_split_timer(): succ. to
>>>>> split (h=0x7f21ba7b15f8)(p=0x7f21ba7b15f8,n=0x7f21ba7b15f8)
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]:
>>>>> DEBUG: pike [pike_funcs.c:234]: clean_routine(): clean node
>>>>> 0x7f21ba98daa0 (kids=(nil); hits=[0,0];leaf=[0,0])
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]:
>>>>> DEBUG: pike [pike_funcs.c:265]: clean_routine(): rmv node
>>>>> 0x7f21ba98daa0[192]
>>>>> May 22 08:58:08 dragon.tekno-soft.it /usr/sbin/kamailio[8441]:
>>>>> DEBUG: pike [ip_tree.c:364]: remove_node(): destroying node
>>>>> 0x7f21ba98daa0
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]:
>>>>> DEBUG: <core> [io_wait.h:617]: io_watch_del(): DBG:
>>>>> io_watch_del (0x8eb2e0, 9, -1, 0x10) fd_no=2 called
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]:
>>>>> DEBUG: <core> [tcp_read.c:1437]: release_tcpconn(): releasing
>>>>> con 0x7f21ba9420c0, state 1, fd=9, id=2
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8454]:
>>>>> DEBUG: <core> [tcp_read.c:1438]: release_tcpconn():
>>>>> extra_data 0x7f21ba941028
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]:
>>>>> DEBUG: <core> [tcp_main.c:3385]: handle_tcp_child():
>>>>> handle_tcp_child: reader response= 7f21ba9420c0, 1 from 2
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]:
>>>>> DEBUG: <core> [io_wait.h:390]: io_watch_add(): DBG:
>>>>> io_watch_add(0x893040, 28, 2, 0x7f21ba9420c0), fd_no=20
>>>>> May 22 08:58:10 dragon.tekno-soft.it /usr/sbin/kamailio[8456]:
>>>>> DEBUG: <core> [tcp_main.c:3515]: handle_tcp_child():
>>>>> handle_tcp_child: CONN_RELEASE 0x7f21ba9420c0 refcnt= 1
>>>>>
>>>>> Cheers,
>>>>> Roberto Fichera.
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Daniel
>>>>>>
>>>>>> On 21/05/14 18:37, Roberto Fichera wrote:
>>>>>>> On 05/21/2014 09:08 AM, Roberto Fichera wrote:
>>>>>>>
>>>>>>> Hi There,
>>>>>>>
>>>>>>>> On 05/20/2014 09:15 PM, Peter Villeneuve wrote:
>>>>>>>>> Hi Roberto,
>>>>>>>>
>>>>>>>> Hi Peter,
>>>>>>>>
>>>>>>>>> Did you ever figure out how to do it?
>>>>>>>>> I'd be interested too.
>>>>>>>>
>>>>>>>> Not yet! I tried other ways, barely workarounds, but I
>>>>>>>> guess I'll have to go into this
>>>>>>>> quite soon because it is the straight way to go. The main
>>>>>>>> problem is the lack of
>>>>>>>> my knowledge of kamailio API so I'll have to study a
bit
>>>>>>>> some code in order to understand
>>>>>>>> how to use it.
>>>>>>>>
>>>>>>>> BTW the idea is to trigger an event route were I'd
like to
>>>>>>>> set all the info regarding
>>>>>>>> the dispatched message including the result of the
>>>>>>>> delivering. I don't know if is possible
>>>>>>>> but the best would be to set all the pseudo-variables so
>>>>>>>> that such event route will be
>>>>>>>> in the right context of the given MSILO message.
>>>>>>>>
>>>>>>>> So, any advice regarding the API would definitively help
>>>>>>>> and put me in the right direction.
>>>>>>>
>>>>>>> Actually I've started to play with the above idea, so
below
>>>>>>> you will find my current implementation
>>>>>>> which seems executed because I see the LM_DBG() log but the
>>>>>>> code within the event route but
>>>>>>> the corresponding script code does not.
>>>>>>>
>>>>>>> Any help?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Roberto Fichera.
>>>>>>>
>>>>>>>
>>>>>>> event_route [msilo:on-delivered] {
>>>>>>> xlog("L_INFO", "MSILO event on-delivered
<$fu> to <$ru>\n");
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> diff --git a/modules/msilo/msilo.c b/modules/msilo/msilo.c
>>>>>>> index 903b3cf..742c48d 100644
>>>>>>> --- a/modules/msilo/msilo.c
>>>>>>> +++ b/modules/msilo/msilo.c
>>>>>>> @@ -281,6 +281,9 @@ static int bind_msilo(msilo_api_t* api)
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> +/* where to go for the local request route
>>>>>>> ("msilo:on-delivered") */
>>>>>>> +int msilo_event_on_delivered=-1; /* default disabled */
>>>>>>> +
>>>>>>> /**
>>>>>>> * init module function
>>>>>>> */
>>>>>>> @@ -480,6 +483,11 @@ static int mod_init(void)
>>>>>>> if(ms_outbound_proxy.s!=NULL)
>>>>>>> ms_outbound_proxy.len =
>>>>>>> strlen(ms_outbound_proxy.s);
>>>>>>>
>>>>>>> + /* check if the on-delivered route event exists or
>>>>>>> not */
>>>>>>> + msilo_event_on_delivered=route_lookup(&event_rt,
>>>>>>> "msilo:on-delivered");
>>>>>>> + if (msilo_event_on_delivered>=0 &&
>>>>>>> event_rt.rlist[msilo_event_on_delivered]==0)
>>>>>>> + msilo_event_on_delivered=-1; /* disable */
>>>>>>> +
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> @@ -1330,6 +1338,26 @@ void m_tm_callback( struct cell *t,
>>>>>>> int type, struct tmcb_params *ps)
>>>>>>> LM_DBG("message <%d> was sent
successfully\n",
>>>>>>> *((int*)ps->param));
>>>>>>> msg_list_set_flag(ml, *((int*)ps->param),
MS_MSG_DONE);
>>>>>>>
>>>>>>> + /* execute the msilo:on-delivered event route */
>>>>>>> + if(unlikely(msilo_event_on_delivered>=0))
>>>>>>> + {
>>>>>>> + int sflag_bk;
>>>>>>> + int backup_route_type;
>>>>>>> + struct run_act_ctx ctx;
>>>>>>> +
>>>>>>> + LM_DBG("executing
>>>>>>> event_route[msilo:on-delivered] (%d)\n",
>>>>>>> msilo_event_on_delivered);
>>>>>>> +
>>>>>>> + sflag_bk = getsflags();
>>>>>>> + backup_route_type = get_route_type();
>>>>>>> +
>>>>>>> + set_route_type(EVENT_ROUTE);
>>>>>>> + init_run_actions_ctx(&ctx);
>>>>>>> + run_top_route(event_rt.rlist[msilo_event_on_delivered],
>>>>>>> ps->req, &ctx);
>>>>>>> +
>>>>>>> + set_route_type(backup_route_type);
>>>>>>> + setsflagsval(sflag_bk);
>>>>>>> + }
>>>>>>> +
>>>>>>> done:
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Roberto Fichera.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Apr 17, 2014 at 4:04 PM, Roberto Fichera
>>>>>>>>> <kernel(a)tekno-soft.it
<mailto:kernel@tekno-soft.it>> wrote:
>>>>>>>>>
>>>>>>>>> On 04/17/2014 10:36 AM, Roberto Fichera wrote:
>>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> > On 04/16/2014 07:15 PM, Roberto Fichera
wrote:
>>>>>>>>> >
>>>>>>>>> > Hi All,
>>>>>>>>> >
>>>>>>>>> >> On 04/16/2014 06:53 PM,
Daniel-Constantin Mierla wrote:
>>>>>>>>> >>> Hello,
>>>>>>>>> >> Ciao Daniel,
>>>>>>>>> >>
>>>>>>>>> >>> most likely the messages are looped
back, be sure
>>>>>>>>> you allow requests from 'myself' without
authentication.
>>>>>>>>> >>>
>>>>>>>>> >>> You can watch loopback interface
with ngrep to see
>>>>>>>>> if the messages are sent out.
>>>>>>>>> >> Yep! Allowing requests from myself
solved the
>>>>>>>>> problem! Thanks!
>>>>>>>>> >>
>>>>>>>>> >> Another thing regarding MSILO, I would
like to
>>>>>>>>> preserve some custom header fields
>>>>>>>>> >> for both instant message and
notification. How can
>>>>>>>>> I do it?
>>>>>>>>> > I was able to solve this issue too, pretty
straight
>>>>>>>>> I mean, there is the extra_hdrs_avp param
>>>>>>>>> > which did the trick. BTW, is there a way to
send
>>>>>>>>> back the notification to the sender that
>>>>>>>>> > the message has been sent correctly via
m_dump(), so
>>>>>>>>> to get a 200 about the given
>>>>>>>>> > m_dump()ed message?
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> I think that this can be solved in a different
way,
>>>>>>>>> the idea is to add an event_route for the msilo
>>>>>>>>> module so that we get notified for each
m_dump()ed
>>>>>>>>> message about the given IM status and
>>>>>>>>> then handle it in the cfg file. So, looking at
the
>>>>>>>>> code within m_tm_callback() it seems that
it's
>>>>>>>>> right place where to add such feature. Since
I'm not a
>>>>>>>>> kamailio developer but I've quite long
>>>>>>>>> time experience in C coding, does anyone can
>>>>>>>>> show/point me to some example about
>>>>>>>>> how to do that?
>>>>>>>>>
>>>>>>>>> Thanks in advance,
>>>>>>>>> Roberto Fichera.
>>>>>>>>>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
10:15 a.m.
On 05/27/2014 08:37 AM, Daniel-Constantin Mierla wrote:
Hello,
Ciao,
you can re-use the lib/kcore/faked_msg.{c,h} in your
code, same being done by many event routes. Alternative is to
build it yourself from the outgoing buffer, which is in transaction structure, inside the
uac field (see tm_cell_t
structure).
Thanks! I'll have a look.
Easier might be to run this event route with the
response sip msg structure -- if you run it only when 200ok is
received, the callback from tm has the response structure.
Yep! The idea is to run it only when a 200 is received and to populate all the
pseudo-variable
with all fields of the delivered message. About the response structure from tm callback,
do you
mean the cell or tmcb_params?
Cheers,
Roberto Fichera.
>
> Cheers,
> Daniel
>
> On 26/05/14 16:46, Roberto Fichera wrote:
>> On 05/26/2014 01:04 PM, Roberto Fichera wrote:
>>
>> Ciao,
>>
>>> [...]
>>>>>>
>>>>>> On 26/05/14 12:13, Roberto Fichera wrote:
>>>>>>> On 05/26/2014 12:03 PM, Daniel-Constantin Mierla wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Ciao!
>>>>>>>
>>>>>>>>
>>>>>>>> good that you sent a reminder -- I checked while offline
traveling, but then forgot to follow up.
>>>>>>>>
>>>>>>>> I expect that ps->req is null in this case, because
there is no request received by kamailio. That results in
>>>>>>>> xlog not doing anything.
>>>>>>>>
>>>>>>>> In other words, I expect the event route being executed,
just the action inside is doesn't do anything in this
>>>>>>>> case.
>>>>>>>
>>>>>>> Does this mean that I'll have to set a "faked"
ps->req in order to get the event route executed?
>>>>>>
>>>>>> that's the safe way. The event route is executed, but many
functions that you can use inside config routing
>>>>>> blocks require a non-null sip message structure. It is the case
of xlog() for example, which simply returns -1 if
>>>>>> request is null.
>>>>>
>>>>> Ok! Can you suggest the safest and reasonable way to setup the
request for this case?
>>>>
>>>> Ah! No! Wait! The event route is executed within a tm callback via
tmb.t_request() so I'd expect a valid ps->req,
>>>> don't you think so?
>>>
>>> I've found how to change the code ... just testing the logic. I'll
get back to you in case.
>>
>> After a while I've found that I can pass a request using the uac_r.cbp field,
so I've fixed the callback
>> to use the passed fields instead a straight int (previously mid==message id) but
I'm not sure how to
>> build a fake sip_msg request regarding the given msilo dumped msg, could you
please give me a
>> tips how to do so?
>>
>> Cheers,
>> Roberto Fichera.
>>
3835
days inactive
3876
days old
20 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Peter Villeneuve -
Roberto Fichera