[SR-Users] Kamailio and MSILO with TLS AORs
Daniel-Constantin Mierla
miconda at gmail.com
Tue May 27 08:37:22 CEST 2014
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,
>
>> [...]
>>>>>
>>>>> 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.
>
>>
>> Cheer,
>> Roberto Fichera.
>>
>>>
>>>>
>>>> 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 at 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 at 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 at tekno-soft.it <mailto:kernel at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140527/267f23a0/attachment.html>
More information about the sr-users
mailing list