Re: [SR-Users] core in dialog module
Hi,
yes, you're totally right, we got the core in other server and I though the
fix was included in the code we compiled in this server, but it wasn't. My
fault.
Now, a very recent copy of the 3.1 git branch is running, Daniel's patch is
included. I'll keep you informed but it should go fine.
Thanks, and sorry for the misunderstanding,
Regards,
Anton
2011/5/13 Timo Reimann
> Hey,
>
>
> On 13.05.2011 11:11, Timo Reimann wrote:
> > On 12.05.2011 15:55, Anton Roman wrote:
> >> my answer is inline:
> >>
> >> 2011/5/12 Timo Reimann >> <mailto:timo.reim...@1und1.de>>
> >> As to the reason of the segfault, the dialog structure or hash table
> may
> >> already be gone when unref_dlg() is called. Can you go to stack #0
> and
> >> tell us what the value of each of the following data structures is
> (use
> >> "p in gdb):
> >>
> >> *dlg
> >> d_table
> >> d_table->entries
> >>
> >>
> >> Here you have:
> >>
> >> (gdb) p *dlg
> >> $1 = {ref = 793790803, next = 0xa0d4b4f20303032, prev =
> >> 0x504953203a616956, h_id = 808333871, h_entry = 1346655535, state =
> >> 775174432,
> >> lifetime = 841888562, start_ts = 892219952, dflags = 808794678, sflags
> >> = 1648046134, toroute = 1668178290, toroute_name = {
> >> s = 0x62344768397a3d68 ,
> >> len = 946221643}, from_rr_nb = 1886534457, tl = {
> >> next = 0x72460a0d30363035, prev = 0x6f6e4122203a6d6f, timeout =
> >> 1869445486}, callid = {
> >> s = 0x6f6e613a7069733c ,
> >> len = 1869445486}, from_uri = {
> >> s = 0x3230322e33322e34 ,
> >> len = 1043739950}, to_uri = {
> >
> > [...]
> >
> > As I suspected, your dialog seems outdated already: The reference count
> > is 793790803, and the Call-ID is supposed to have a rough 2 billions
> > characters. That's what I call unique. :)
> >
> > I could ask you for more details on the dump but it'd probably be
> > easiest if I could take a direct (gdb-)look at it. Would you mind
> > sending it to me in private (i.e., no CC to the mailing list) to the
> > address I am writing from?
>
> I (and Marius -- credits!) digged through your coredump and found a few
> curiosities. Before I bug you with the details, let me just say this:
> There might be something wrong the dialog reference counter that
> determines when a dialog is a to be removed from the hash table. In
> fact, your call stack indicates that an unreference operation was
> attempted on a hash table which looks empty:
>
> (gdb) frame 0
> #0 unref_dlg (dlg=0x7f08a9f67da8, cnt=1) at dlg_hash.c:598
> 598 dlg_lock( d_table, d_entry);
> (gdb) p *d_table->entries
> $53 = {first = 0x0, last = 0x0, next_id = 1124074261, lock_idx = 0}
>
>
> Looking through the mailing-list archive, I noticed you brought
> attention to another reference counter-related bug which Daniel provided
> a fix for with commit 2c28a251a. Since you reported that no more issues
> appeared with that fixed version, I just backported the patch into 3.1.
> However, I can see from your core dump that you are not using a Kamailio
> version that includes the fix.
>
> Before we continue with any bug hunting, could you try a version of
> Kamailio that comes with Daniel's "safer unref of terminated dialogs"
> patch? This can be master branch copy or a recent copy of the 3.1 git
> branch. I'd suggest the latter so we can ensure that no bleeding-edge
> features added to the dialog module distort our analysis.
>
> Thanks and
>
>
> Cheers,
>
> --Timo
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] core in dialog module
Hello,
my answer is inline:
2011/5/12 Timo Reimann
> Hey,
>
>
> On 12.05.2011 12:37, Anton Roman wrote:
> > we got a core in dialog module. We are using kamailio 3.1.2. Below you
> > can find a full backtrace from the dump and the Kamailio compilation
> > options. Please, if you need further information don't hesitate to ask
> > me for it. I can't precise the situation when it is generated because
> > we have a quite high load in this server.
>
> The call path seems to be like this:
>
> transaction timer fires -> tm module walking through callback list finds
> unref_dlg() -> tm module calls unref_dlg() -> boom.
>
> I wonder why unref_dlg() was registered as a tm callback in the first
> place -- the dialog module shouldn't do that. Are you using any custom
> modules that would possibly do such registrations?
>
No, we aren't. We got the code of all the modules directly from the git
repository.
> As to the reason of the segfault, the dialog structure or hash table may
> already be gone when unref_dlg() is called. Can you go to stack #0 and
> tell us what the value of each of the following data structures is (use
> "p in gdb):
>
> *dlg
> d_table
> d_table->entries
>
Here you have:
(gdb) p *dlg
$1 = {ref = 793790803, next = 0xa0d4b4f20303032, prev = 0x504953203a616956,
h_id = 808333871, h_entry = 1346655535, state = 775174432,
lifetime = 841888562, start_ts = 892219952, dflags = 808794678, sflags =
1648046134, toroute = 1668178290, toroute_name = {
s = 0x62344768397a3d68 , len =
946221643}, from_rr_nb = 1886534457, tl = {
next = 0x72460a0d30363035, prev = 0x6f6e4122203a6d6f, timeout =
1869445486}, callid = {
s = 0x6f6e613a7069733c , len =
1869445486}, from_uri = {
s = 0x3230322e33322e34 , len =
1043739950}, to_uri = {
s = 0x396637643173613d , len =
221656933}, req_uri = {
s = 0x34333a7069733c20 , len =
925972025}, tag = {{
s = 0x33322e3539314030 , len =
942747189}, {
s = 0x743b3e303630353a , len =
1178429281}}, cseq = {{
s = 0x364134322d344434 , len =
1631848973}, {
s = 0x203932202c697246 , len =
544236883}}, route_set = {{
s = 0x343a30313a333020 , len =
1296506937}, {
s = 0x203a44492d6c6c61 , len =
1630549808}}, contact = {{
s = 0x6639633663313634 , len =
858808881}, {
s = 0x6464363632663631 , len =
775174464}}, bind_addr = {0x530a0d36352e3230,
0x43203a7265767265}, cbs = {first = 0x5049532d6f637369, types =
1702125895}, profile_links = 0x782e32312d534f49}
(gdb) p d_table
$2 = (struct dlg_table *) 0x7f08a9e38ee0
(gdb) p d_table->entries
$3 = (struct dlg_entry *) 0x7f08a9e38f00
(gdb) info f
Stack level 0, frame at 0x7fff49059980:
rip = 0x7f08cc18fa39 in unref_dlg (dlg_hash.c:598); saved rip
0x7f08ce92fa02
called by frame at 0x7fff49059a10
source language c.
Arglist at 0x7fff490598a8, args: dlg=0x7f08a9f67da8, cnt=1
Locals at 0x7fff490598a8, Previous frame's sp is 0x7fff49059980
Saved registers:
rbx at 0x7fff49059948, rbp at 0x7fff49059950, r12 at 0x7fff49059958, r13
at 0x7fff49059960, r14 at 0x7fff49059968, r15 at 0x7fff49059970,
rip at 0x7fff49059978
(gdb)
>
> Cheers,
>
> --Timo
>
>
Thank you very much,
Regards,
Antón
>
>
> > (gdb) bt full
> > #0 unref_dlg (dlg=0x7f08a9f67da8, cnt=1) at dlg_hash.c:598
> > d_entry = (struct dlg_entry *) 0x7f10304b8b68
> > #1 0x7f08ce92fa02 in run_trans_callbacks_internal
> > (cb_lst=0x7f08aa203e98, type=32768, trans=0x7f08aa203e28,
> > params=0x7fff49059a10)
> > at t_hooks.c:290
> > cbp = (struct tm_callback *) 0x7f08a9f6e7e0
> > backup_from = (avp_list_t *) 0x8b3330
> > backup_to = (avp_list_t *) 0x8b3338
> > backup_dom_from = (avp_list_t *) 0x8b3340
> > backup_dom_to = (avp_list_t *) 0x8b3348
> > backup_uri_from = (avp_list_t *) 0x8b3320
> > backup_uri_to = (avp_list_t *) 0x8b3328
> > #2 0x7f08ce92fc56 in run_trans_callbacks (type=32768, trans= > optimized out>, req=0x1, rpl=0x7f10304b8b68, code=-868566200)
> > at t_hooks.c:317
> > params = {req = 0x0, rpl = 0x0, param = 0x7f08a9f6e7f0, code = 0,
> > flags = 0, branch = 0, t_rbuf = 0x0, dst = 0x0, send_buf = {
> > s = 0x0, len = 0}}
> > #3 0x7f08ce915b36 in free_cell (dead_cell=0x7f08aa203e28) at
> > h_table.c:136
> > b =
> > i =
> > rpl =
> > tt =
> > foo =
> > cbs =
> > ---Type to continue, or q to quit---
> > __FUNCTION__ = "free_cell"
> > #4 0x7f08ce9319f1 in wait_handler (ti=,
> > wait_tl=, data=) at timer.c:645
> > p_cell = (struct cell *) 0x7f08aa203e28
> > #5 0x00513d8f in timer_main () at timer.c:894
> > No locals.
> > #6 0x000
[SR-Users] core in dialog module
Hi all,
we got a core in dialog module. We are using kamailio 3.1.2. Below you can
find a full backtrace from the dump and the Kamailio compilation options.
Please, if you need further information don't hesitate to ask me for it. I
can't precise the situation when it is generated because we have a quite
high load in this server.
Thanks in advance.
Antón
(gdb) bt full
#0 unref_dlg (dlg=0x7f08a9f67da8, cnt=1) at dlg_hash.c:598
d_entry = (struct dlg_entry *) 0x7f10304b8b68
#1 0x7f08ce92fa02 in run_trans_callbacks_internal
(cb_lst=0x7f08aa203e98, type=32768, trans=0x7f08aa203e28,
params=0x7fff49059a10)
at t_hooks.c:290
cbp = (struct tm_callback *) 0x7f08a9f6e7e0
backup_from = (avp_list_t *) 0x8b3330
backup_to = (avp_list_t *) 0x8b3338
backup_dom_from = (avp_list_t *) 0x8b3340
backup_dom_to = (avp_list_t *) 0x8b3348
backup_uri_from = (avp_list_t *) 0x8b3320
backup_uri_to = (avp_list_t *) 0x8b3328
#2 0x7f08ce92fc56 in run_trans_callbacks (type=32768, trans=, req=0x1, rpl=0x7f10304b8b68, code=-868566200)
at t_hooks.c:317
params = {req = 0x0, rpl = 0x0, param = 0x7f08a9f6e7f0, code = 0, flags
= 0, branch = 0, t_rbuf = 0x0, dst = 0x0, send_buf = {
s = 0x0, len = 0}}
#3 0x7f08ce915b36 in free_cell (dead_cell=0x7f08aa203e28) at
h_table.c:136
b =
i =
rpl =
tt =
foo =
cbs =
---Type to continue, or q to quit---
__FUNCTION__ = "free_cell"
#4 0x7f08ce9319f1 in wait_handler (ti=,
wait_tl=, data=) at timer.c:645
p_cell = (struct cell *) 0x7f08aa203e28
#5 0x00513d8f in timer_main () at timer.c:894
No locals.
#6 0x0046501b in main_loop () at main.c:1618
i = 4
pid =
si = (struct socket_info *) 0x0
si_desc = "udp receiver child=3
sock=XXX.XXX.XXX.XX:\000\000\000\210�\231\000\000\000\000\000\031", '\0'
, "\001\000\000\000\000\000\000\000�\215\213", '\0'
, "\004", '\0' ,
"\b\236\005I�\177\000\000\227%J\000\000\000\000"
#7 0x00467873 in main (argc=,
argv=0x7fff49059e08) at main.c:2398
cfg_stream = (FILE *) 0x12e1010
c =
r =
tmp = 0x7fff4905ae90 ""
tmp_len = 32520
port =
proto =
ret =
seed = 1235801225
---Type to continue, or q to quit---
rfd = 4
debug_save =
debug_flag = 0
dont_fork_cnt = 0
n_lst =
p =
(gdb)
(gdb) quit
kamailio2:/var/kamailio# kamailio -V
version: kamailio 3.1.2 (x86_64/linux) eb24c1-dirty
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: eb24c1 -dirty
compiled on 09:35:52 Apr 28 2011 with gcc 4.3.2
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] problem unreferencing dialog in dialog module
Hi,
more than 3 millions calls have been processed and no problem (crash,
increment in memory allocation...) has been noticed since the update, so
this check works for us.
Thanks a lot,
regards
2011/3/4 Daniel-Constantin Mierla
> Hello,
>
> just committed a safety check for this case. If anyone can give it some
> tests, then we can backport.
>
> I will analyze to see why it got in such case, but anyhow it is better and
> safer to detect bogus dereferences to dialogs and not crash.
>
> Thanks,
> Daniel
>
>
> On 3/3/11 11:34 AM, Timo Reimann wrote:
>
>> Argh:
>>
>>
>> On 03.03.2011 11:11, Timo Reimann wrote:
>>
>>> What I can tell though is that the crash happens because too much dialog
>>> reference counter decrementing takes place. Although I have no clue why,
>>>
>>^
>>
>> ...the crash happens,
>>
>> I believe the implementation of unref_dlg_unsafe() (a macro) could be
>>> somewhat more robust by not unlinking and destroying a dialog when the
>>> counter drops below zero. That is, instead of running the following block
>>>
>>> if ((_dlg)->ref<=0) { \
>>> unlink_unsafe_dlg( _d_entry, _dlg);\
>>> LM_DBG("ref<=0 for dialog %p\n",_dlg);\
>>> destroy_dlg(_dlg);\
>>> }\
>>>
>>
>> for _dlg->ref<= 0, I see no reason to change the compare operator to ==.
>>>
>> I see no reason *not* to change compare operator to ==. That is, I want
>> the block to execute iff the reference counter is found to be zero.
>>
>>
>> --Timo
>>
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> --
> Daniel-Constantin Mierla
> http://www.asipto.com
>
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] problem unreferencing dialog in dialog module
Ok, I updated the code in the server. I'm testing the changes on Tuesday and I'll send feedback to the list. We found dialog module very useful because of the information and functionality it provides. For example, we are using its exported function dlg_end_dlg to cleanly end all the active calls when stopping Kamailio is required for maintenance reasons. We are also using the dlg_bridge function to implement click-to-dial applications and it works fine. On the other hand, in the logs of the server we detected the unreference problem, we got the logs showed below quite often. I don 't know if it can be related to the unreference problem. Since it has a CRITICAL log level I'm not sure if this is so because it can mean a real problem or Kamailio can safety deal with it: Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: CRITICAL: dialog [dlg_hash.c:615]: bogus event 5 in state 4 for dlg *0x7f2d0a3d30e0*[306:1818049706] with clid ' 92515995-3508071667-342...@usmiap1etx02.mydomain.com' and tags '3508071667-342428' '7A242CC-0' Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: dialog [dlg_hash.c:770]: dialog *0x7f2d0a3d30e0* changed from state 4 to state 4, due event 5 Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=4077 , global msg id=4076 , T on entrance=(nil) Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=356, isACK=0 Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_lookup.c:470]: DEBUG: RFC3261 transaction matched, tid=3178c7ec929daf0e4ade2b303de82a20 Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_lookup.c:728]: DEBUG: t_lookup_request: transaction found (T=0x7f2d0a82bca0) Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_reply.c:1430]: DEBUG: reply retransmitted. buf=0x7f2d2eff4160: SIP/2.0 5..., shmem=0x7f2d0a72cb90: SIP/2.0 5 Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: dialog [dlg_hash.c:599]: unref dlg *0x7f2d0a3d30e0* with 1 -> 3 Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: [usr_avp.c:646]: >From dlg_hash.h ... DLG_STATE_CONFIRMED4 /*!< confirmed dialog */ ... DLG_EVENT_REQPRACK 5 /*!< PRACK request */ ... I understand it means we are receiving a PRACK in a confirmed dialog (ACK received), doesn't it? I guess it can be due either to an error of the SIP stack of the caller side or this PRACK is a rtx due to networking issues (not probable, I think). Thanks a lot, regards Antón 2011/3/4 Daniel-Constantin Mierla > Hello, > > > On 3/3/11 10:19 AM, Anton Roman wrote: > > Hello, > > thanks for your quick reply, my answer is inline. > > 2011/3/2 Daniel-Constantin Mierla > >> Hello, >> >> looks like related to the callbacks for dialog module. Are you loading >> other modules that require dialog module? >> > > we are using some features of dialog module such as ending dialogs after a > timeout period, and we are using engage_mediaproxy() function, as well. It's > an old configuration we had to put in production with no time enough to > test. Do you recommend not to use dialog module if not strictly required? > > > usage of dialog module was always safe and working great for me. But I use > it mostly alone, never with mediaproxy module, just with pua_dialoginfo > module in some cases. From the logs, the crash was related to the callback > system exported by dialog module for the other modules willing to hook into > dialog, it is why I asked about the other modules to be sure there is at > list one binding to dialog. > > So, like with other modules, if there is a problem discovered there, it is > important that we fix it - this is a module used a lot by many. Therefore > usage is encouraged when needed :-) > > Cheers, > Daniel > > > -- > Daniel-Constantin Mierlahttp://www.asipto.com > > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] problem unreferencing dialog in dialog module
Hello,
thanks for your quick reply, my answer is inline.
2011/3/2 Daniel-Constantin Mierla
> Hello,
>
> looks like related to the callbacks for dialog module. Are you loading
> other modules that require dialog module?
>
we are using some features of dialog module such as ending dialogs after a
timeout period, and we are using engage_mediaproxy() function, as well. It's
an old configuration we had to put in production with no time enough to
test. Do you recommend not to use dialog module if not strictly required?
>
> Checking the time staps from the acc and the crash log, the BYE for the
> dialog was before the crash but the To-tag is not printed from dlg_hash.c,
> although it is in the acc for INVITE and BYE. Do you have parallel forking
> in front of this SIP server? I mean, is there another proxy that can do
> parallel forking then send two or more branches to this instance?
>
> AFAIK the the client who is sending that calls is not doing parallel
forking, they are sending calls over a SIP trunk to our Kamailio. They are
calling to PSTN numbers and we are sending that calls to a gateway, so they
shouldn't do parallel forking, I'll get some traces to check it.
> I will dig in more to see what went wrong there.
>
> I got the attached debug level logs for the reported problem, hope it
helps. I'm still trying to find out why the core is not being generated.
> Thanks,
> Daniel
>
Thanks a lot,
Anton
>
>
> On 3/2/11 4:34 PM, Anton Roman wrote:
>
> Hi all,
>
> we are running Kamailio 3.1.2 in a production environment, using the dialog
> module, and it crashed two hours ago.
>
>
> Here you have the logs we got (addtional log fragments with the acc records
> involved in this call are appended at the end of the mail):
>
> Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28927]: CRITICAL: dialog
> [dlg_hash.c:599]: bogus ref -1 with cnt 1 for dlg 0x7f23f472db30
> [2490:1070436595] with clid 'e0a20cb844d211e0acd8001422093865@'
> and tags '1577886432-3759264324-335599788-1698171170' ''
> Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28927]: :
> [mem/q_malloc.c:446]: BUG: qm_free: freeing already freed pointer, first
> free: dialog: dlg_cb.c: destroy_dlg_callbacks_list(80) - aborting
> Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: ALERT:
> [main.c:741]: child process 28927 exited by a signal 6
> Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: ALERT:
> [main.c:744]: core was not generated
> Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: INFO:
> [main.c:756]: INFO: terminating due to SIGCHLD
> Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28948]: INFO:
> [main.c:807]: INFO: signal 15 received
> Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28942]: INFO:
> [main.c:807]: INFO: signal 15 received
>
> We get the kamailio code from git last week:
>
> sercmd> core.info
> {
> version: kamailio 3.1.2
> id: 4ace86
> compiler: gcc 4.3.2
> compiled: 09:12:36 Feb 23 2011
> flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
> USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP,
> PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
> HAVE_RESOLV_RES
> }
>
> The problem looks like this other one already fixed:
> http://lists.sip-router.org/pipermail/sr-users/2009-November/027351.html
>
> We set the Kamailio to debug level in case it happens again.
>
> On the other side, I need to know why the core is not been generated. I
> have already checked the points mentioned in
> http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:corefiles
>
> 1. disable_core_dump is not set in the config file.
>
> 2. From /etc/default/kamailio:
> ...
> DUMP_CORE=yes
> ...
>
> 2. From /etc/init.d/kamailio:
> ...
> if test "$DUMP_CORE" = "yes" ; then
> # set proper ulimit
> ulimit -c unlimited
>
> # directory for the core dump files
> COREDIR=/home/corefiles
> [ -d $COREDIR ] || mkdir $COREDIR
> chmod 777 $COREDIR
> echo "$COREDIR/core.%e.sig%s.%p" > /proc/sys/kernel/core_pattern
> fi
> ...
>
> 4. Writting permissions of $COREDIR
>
> ls -hall /home
> ...
> drwxrwxrwx 2 root root 4.0K 2010-12-21 09:15 corefiles
> ...
>
> What else should I check?
>
> Thanks in advance,
> regards
>
> Antón
>
>
> *Acc records related to the dialog whose destruction causes the problem:*
>
> Mar 2 14:42:44 kamailio2 /usr/local/sbin/kamailio[28902]: NOTICE: acc
> [acc.c:275]: ACC: transaction answered:
> timestamp=12990
[SR-Users] problem unreferencing dialog in dialog module
Hi all,
we are running Kamailio 3.1.2 in a production environment, using the dialog
module, and it crashed two hours ago.
Here you have the logs we got (addtional log fragments with the acc records
involved in this call are appended at the end of the mail):
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28927]: CRITICAL: dialog
[dlg_hash.c:599]: bogus ref -1 with cnt 1 for dlg 0x7f23f472db30
[2490:1070436595] with clid 'e0a20cb844d211e0acd8001422093865@'
and tags '1577886432-3759264324-335599788-1698171170' ''
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28927]: :
[mem/q_malloc.c:446]: BUG: qm_free: freeing already freed pointer, first
free: dialog: dlg_cb.c: destroy_dlg_callbacks_list(80) - aborting
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: ALERT:
[main.c:741]: child process 28927 exited by a signal 6
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: ALERT:
[main.c:744]: core was not generated
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: INFO:
[main.c:756]: INFO: terminating due to SIGCHLD
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28948]: INFO:
[main.c:807]: INFO: signal 15 received
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28942]: INFO:
[main.c:807]: INFO: signal 15 received
We get the kamailio code from git last week:
sercmd> core.info
{
version: kamailio 3.1.2
id: 4ace86
compiler: gcc 4.3.2
compiled: 09:12:36 Feb 23 2011
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
}
The problem looks like this other one already fixed:
http://lists.sip-router.org/pipermail/sr-users/2009-November/027351.html
We set the Kamailio to debug level in case it happens again.
On the other side, I need to know why the core is not been generated. I have
already checked the points mentioned in
http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:corefiles
1. disable_core_dump is not set in the config file.
2. From /etc/default/kamailio:
...
DUMP_CORE=yes
...
2. From /etc/init.d/kamailio:
...
if test "$DUMP_CORE" = "yes" ; then
# set proper ulimit
ulimit -c unlimited
# directory for the core dump files
COREDIR=/home/corefiles
[ -d $COREDIR ] || mkdir $COREDIR
chmod 777 $COREDIR
echo "$COREDIR/core.%e.sig%s.%p" > /proc/sys/kernel/core_pattern
fi
...
4. Writting permissions of $COREDIR
ls -hall /home
...
drwxrwxrwx 2 root root 4.0K 2010-12-21 09:15 corefiles
...
What else should I check?
Thanks in advance,
regards
Antón
*Acc records related to the dialog whose destruction causes the problem:*
Mar 2 14:42:44 kamailio2 /usr/local/sbin/kamailio[28902]: NOTICE: acc
[acc.c:275]: ACC: transaction answered:
timestamp=1299073364;method=INVITE;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@;code=200;reason=OK;src_user=;src_domain=;dst_ouser=;dst_user=;dst_domain=10.90.1.251;src_ip=
...
Mar 2 14:42:44 kamailio2 /usr/local/sbin/kamailio[28920]: NOTICE: acc
[acc.c:275]: ACC: request acknowledged:
timestamp=1299073364;method=ACK;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@;code=200;reason=OK;src_user=;src_domain=;dst_ouser=;dst_user=;dst_domain=10.90.1.251;src_ip=
...
Mar 2 14:43:00 kamailio2 /usr/local/sbin/kamailio[28903]: ERROR:
Re: [SR-Users] kamctl fifo not responding
Hello, I've already got the fifo listener PID. Kamailio had to be restarted and now it's working fine. When it gets unresponsive again I'll check it with gdb. I'll keep you informed. On the other hand, we use fifo pipe quite often to update hastables (* sht_reload*) and to get hashtable dumps (*sht_dump*). These HTs are used to implement a CAC mechanism. We also regularly use the *cr_reload_routes*command. Thanks. Regards, Antón 2011/1/18 Daniel-Constantin Mierla > Hello, > > do you have ctl module loaded? If yes, you can connect with sercmd and get > the pid of the fifo listener: > > sercmd> ps > > Then connect with gdb: > > gdb /path/to/kamailio pidoffifolistener > > and get the backtrace. > > That should show what the fifo process is doing. > > Also, you can get the pid of fifo process at startup, with kamctl ps, store > it for the time when it blocks in order to use it with gdb. > > I haven't encountered this issue, do you have lot of communication over > fifo file? How many commands and how often are sent through fifo file? > > Cheers, > Daniel > > > > On 1/18/11 11:52 AM, Anton Roman wrote: > > Hi, > > my reply is inline > > 2011/1/18 Daniel-Constantin Mierla > >> Hello, >> >> do you get anything in kamailio log messages when the fifo is not >> responding? >> > > No, I didn't find anything regarding the fifo command in the logs. > >> >> What version of kamailio do you have? >> > > kamailio-3.0.2, the last time we updated the code was on August 1st, since > then it is in production. > >> >> Removing and creating a new one will not help, since kamailio will not >> reopen, so practically will still use the old file descriptor. >> > > It makes all the sense. > >> >> Cheers, >> Daniel >> >> Thank you very much, > regards, > Anton > >> >> On 1/18/11 10:54 AM, Anton Roman wrote: >> >> Hi all, >> >> I'm having trouble trying to execute fifo commands with "kamctl fifo >> ". Just after restarting Kamailio it works fine, however, sometimes >> after some days running it doesn't respond. >> >> kamailio1:~#* kamctl fifo which* >> >> It doesn't respond so I input *Crtl+c* and I get: >> /usr/local/lib/kamailio//kamctl/kamctl.fifo: line 89: /tmp/kamailio_fifo: >> Interrupted system call >> >> If I delete and create the fifo file again (with "rm /tmp/kamailio_fifo" >> and "mkfifo /tmp/kamailio_fifo" and "chmod 660 /tmp/kamailio_fifo") it keeps >> not responding. >> >> Any help is welcome, what can be happening? Below you can find info about >> the pipe and the running kamailio. >> >> Thanks in advance, >> Best regards >> >> Antón >> >> >> >> kamailio1:~# *ls -hall /tmp/kamailio_fifo * >> prw-rw 1 root root 0 ene 17 12:01 /tmp/kamailio_fifo >> >> After deleting and creating the fifo file again: >> >> kamailio1:~# *ls -hall /tmp/kamailio_fifo * >> prw-rw-r-- 1 root root 0 ene 18 10:28 /tmp/kamailio_fifo >> >> kamailio1:~#* ps -ef | grep kama* >> root 17369 17245 0 10:12 pts/000:00:00 grep kama >> kamailio 23277 1 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio >> -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio >> kamailio 23289 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio >> -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio >> kamailio 23291 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio >> -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio >> kamailio 23293 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio >> -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio >> kamailio 23294 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio >> -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio >> kamailio 23295 23277 0 Jan15 ?00:01:14 /usr/local/sbin/kamailio >> -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio >> kamailio 23299 23277 0 Jan15 ?00:01:13 /usr/local/sbin/kamailio >> -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio >> kamailio 23300 23277 0 Jan15 ?00:01:13 /usr/local/sbin/kamailio >> -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio >> kamailio 23303 23277 0 Jan15 ?00:01:13 /usr/local/sbin/kamailio >> -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio >> kamailio 23305 23277 0 Jan15 ?00:05:29 /usr/lo
Re: [SR-Users] kamctl fifo not responding
Hi, my reply is inline 2011/1/18 Daniel-Constantin Mierla > Hello, > > do you get anything in kamailio log messages when the fifo is not > responding? > No, I didn't find anything regarding the fifo command in the logs. > > What version of kamailio do you have? > kamailio-3.0.2, the last time we updated the code was on August 1st, since then it is in production. > > Removing and creating a new one will not help, since kamailio will not > reopen, so practically will still use the old file descriptor. > It makes all the sense. > > Cheers, > Daniel > > Thank you very much, regards, Anton > > On 1/18/11 10:54 AM, Anton Roman wrote: > > Hi all, > > I'm having trouble trying to execute fifo commands with "kamctl fifo > ". Just after restarting Kamailio it works fine, however, sometimes > after some days running it doesn't respond. > > kamailio1:~#* kamctl fifo which* > > It doesn't respond so I input *Crtl+c* and I get: > /usr/local/lib/kamailio//kamctl/kamctl.fifo: line 89: /tmp/kamailio_fifo: > Interrupted system call > > If I delete and create the fifo file again (with "rm /tmp/kamailio_fifo" > and "mkfifo /tmp/kamailio_fifo" and "chmod 660 /tmp/kamailio_fifo") it keeps > not responding. > > Any help is welcome, what can be happening? Below you can find info about > the pipe and the running kamailio. > > Thanks in advance, > Best regards > > Antón > > > > kamailio1:~# *ls -hall /tmp/kamailio_fifo * > prw-rw 1 root root 0 ene 17 12:01 /tmp/kamailio_fifo > > After deleting and creating the fifo file again: > > kamailio1:~# *ls -hall /tmp/kamailio_fifo * > prw-rw-r-- 1 root root 0 ene 18 10:28 /tmp/kamailio_fifo > > kamailio1:~#* ps -ef | grep kama* > root 17369 17245 0 10:12 pts/000:00:00 grep kama > kamailio 23277 1 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23289 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23291 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23293 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23294 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23295 23277 0 Jan15 ?00:01:14 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23299 23277 0 Jan15 ?00:01:13 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23300 23277 0 Jan15 ?00:01:13 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23303 23277 0 Jan15 ?00:01:13 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23305 23277 0 Jan15 ?00:05:29 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23306 23277 0 Jan15 ?00:05:33 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23309 23277 0 Jan15 ?00:05:30 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23311 23277 0 Jan15 ?00:05:31 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23312 23277 0 Jan15 ?00:00:02 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23313 23277 0 Jan15 ?00:00:39 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23315 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23320 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23321 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23322 23277 0 Jan15 ?00:00:05 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > kamailio 23323 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P > /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio > &g
[SR-Users] kamctl fifo not responding
Hi all, I'm having trouble trying to execute fifo commands with "kamctl fifo ". Just after restarting Kamailio it works fine, however, sometimes after some days running it doesn't respond. kamailio1:~#* kamctl fifo which* It doesn't respond so I input *Crtl+c* and I get: /usr/local/lib/kamailio//kamctl/kamctl.fifo: line 89: /tmp/kamailio_fifo: Interrupted system call If I delete and create the fifo file again (with "rm /tmp/kamailio_fifo" and "mkfifo /tmp/kamailio_fifo" and "chmod 660 /tmp/kamailio_fifo") it keeps not responding. Any help is welcome, what can be happening? Below you can find info about the pipe and the running kamailio. Thanks in advance, Best regards Antón kamailio1:~# *ls -hall /tmp/kamailio_fifo * prw-rw 1 root root 0 ene 17 12:01 /tmp/kamailio_fifo After deleting and creating the fifo file again: kamailio1:~# *ls -hall /tmp/kamailio_fifo * prw-rw-r-- 1 root root 0 ene 18 10:28 /tmp/kamailio_fifo kamailio1:~#* ps -ef | grep kama* root 17369 17245 0 10:12 pts/000:00:00 grep kama kamailio 23277 1 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23289 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23291 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23293 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23294 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23295 23277 0 Jan15 ?00:01:14 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23299 23277 0 Jan15 ?00:01:13 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23300 23277 0 Jan15 ?00:01:13 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23303 23277 0 Jan15 ?00:01:13 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23305 23277 0 Jan15 ?00:05:29 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23306 23277 0 Jan15 ?00:05:33 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23309 23277 0 Jan15 ?00:05:30 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23311 23277 0 Jan15 ?00:05:31 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23312 23277 0 Jan15 ?00:00:02 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23313 23277 0 Jan15 ?00:00:39 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23315 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23320 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23321 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23322 23277 0 Jan15 ?00:00:05 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio kamailio 23323 23277 0 Jan15 ?00:00:00 /usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 512 -u kamailio -g kamailio ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] no Contact in REFER generated with dlg_bridge
Hi,
sorry for my late reply.
I hardcoded the Contact header in dialog/dlg_transfer.c file. It is not a
very elegant way, but I had a short time to fix it :-)
Attached you can find a diff output with the changes I made. Besides the
Contact, I had to add more headers for compatibility reasons both to INVITE
and REFER message.
I think a solution would be to add two params: "bridge_invite_hdrs" and
"bridge_refer_hdrs", to manually include all the headers needed in initial
INVITE and REFER (e.g.: modparam("dialog", "bridge_invite_hdrs", "Contact:
\r\nSupported: 100rel\r\nContent-Type:
application/sdp\r\n")). Perhaps these params could be a bit confusing and
error-prone for new users, however they would be quite useful.
Comments are welcome.
Regards,
Anton
2010/7/1 Daniel-Constantin Mierla
> Hello,
>
>
> On 5/27/10 3:32 PM, Anton Roman wrote:
>
> Hi,
>
> regarding the missing Contact header in the REFER message, it can be solved
> by including some lines in /modules_k/dialog/dlg_ transfer.c. In this file,
> the Contact of the initial INVITE generated with dlg_bridge command can be
> easily changed as well.
>
> do you have a patch that you can send for adding the contact header?
>
> Cheers,
> Daniel
>
>
> The problem now is only in the processing of the ACK generated by the TM
> module. When this ACK leaves the Kamailio server the branch value of the
> topmost Via header is '0'.
>
> Below you can find the debug output where the ACK is generated and routed
> by Kamailio. Any idea about where the error can be?
>
> thanks in advance,
> regards
>
> Anton
>
>
> 11(5056) DEBUG: tm [t_msgbuilder.c:791]: building ACK for out-of-dialog
> INVITE (using RS in RR set).
> 11(5056) DEBUG: tm [t_msgbuilder.c:967]: ACK RURI: `sip:2...@10.1.3.15:5061',
> NH: `sip:10.1.2.122;lr=on'.
> 11(5056) DEBUG: tm [t_reply.c:1059]: ->>>>>>>>> T_code=180, new_code=200
> 11(5056) DEBUG: tm [t_reply.c:1794]: DEBUG: local_reply: branch=0, save=0,
> winner=0
> 11(5056) DEBUG: tm [t_reply.c:356]: DEBUG: update_totag_set: new totag
> 11(5056) DEBUG: tm [t_reply.c:1831]: DEBUG: local transaction completed
> 11(5056) DEBUG: tm [t_hooks.c:288]: DBG: trans=0x7f9767eb1268, callback
> type 256, id 0 entered
> 11(5056) DEBUG: dialog [dlg_transfer.c:207]: completed with status 200
> 11(5056) DEBUG: [parser/parse_to.c:179]: DEBUG: add_param:
> tag=533cb9e91f4b999cf76861cbb9ed54ed-3bcd
> 9(5052) DEBUG: [parser/msg_parser.c:612]: SIP Request:
> 9(5052) DEBUG: [parser/msg_parser.c:614]: method:
> 9(5052) DEBUG: [parser/msg_parser.c:616]: uri: <
> sip:2...@10.1.3.15:5061>
> 9(5052) DEBUG: [parser/msg_parser.c:618]: version:
> 9(5052) DEBUG: [parser/parse_via.c:1283]: Found param type 232,
> = ; state=16
> 9(5052) DEBUG: [parser/parse_via.c:2296]: end of header reached,
> state=5
> 9(5052) DEBUG: [parser/msg_parser.c:500]: parse_headers: Via found,
> flags=2
> 9(5052) DEBUG: [parser/msg_parser.c:502]: parse_headers: this is
> the first via
> 9(5052) DEBUG: [receive.c:137]: After parse_msg...
> 9(5052) DEBUG: [receive.c:177]: preparing to run routing scripts...
> 9(5052) DEBUG: sl [sl_funcs.c:335]: to late to be a local ACK!
> 9(5052) DEBUG: [parser/parse_to.c:179]: DEBUG: add_param:
> tag=94cf927f9c6eed24i1
> 9(5052) DEBUG: [parser/parse_to.c:808]: end of header reached,
> state=29
> 9(5052) DEBUG: [parser/msg_parser.c:174]: DEBUG: get_hdr_field:
> [43]; uri=[sip:2...@10.1.2.122 ]
> 9(5052) DEBUG: [parser/msg_parser.c:176]: DEBUG: to body [
> sip:2...@10.1.2.122 ]
> 9(5052) DEBUG: [parser/msg_parser.c:154]: get_hdr_field: cseq
> : <10>
> 9(5052) DEBUG: [parser/msg_parser.c:188]: DEBUG: get_hdr_body :
> content_length=0
> 9(5052) DEBUG: [parser/msg_parser.c:90]: found end of header
> 9(5052) DEBUG: maxfwd [mf_funcs.c:66]: max_forwards header not found!
> 9(5052) DEBUG: [parser/parse_to.c:179]: DEBUG: add_param:
> tag=533cb9e91f4b999cf76861cbb9ed54ed-3bcd
> 9(5052) DEBUG: [parser/parse_to.c:808]: end of header reached,
> state=29
> 9(5052) DEBUG: sanity [mod_sanity.c:220]: all sanity checks passed
> 9(5052) ERROR:
Re: [SR-Users] no Contact in REFER generated with dlg_bridge
Hi, regarding the missing Contact header in the REFER message, it can be solved by including some lines in /modules_k/dialog/dlg_ transfer.c. In this file, the Contact of the initial INVITE generated with dlg_bridge command can be easily changed as well. The problem now is only in the processing of the ACK generated by the TM module. When this ACK leaves the Kamailio server the branch value of the topmost Via header is '0'. Below you can find the debug output where the ACK is generated and routed by Kamailio. Any idea about where the error can be? thanks in advance, regards Anton 11(5056) DEBUG: tm [t_msgbuilder.c:791]: building ACK for out-of-dialog INVITE (using RS in RR set). 11(5056) DEBUG: tm [t_msgbuilder.c:967]: ACK RURI: `sip:2...@10.1.3.15:5061', NH: `sip:10.1.2.122;lr=on'. 11(5056) DEBUG: tm [t_reply.c:1059]: -> T_code=180, new_code=200 11(5056) DEBUG: tm [t_reply.c:1794]: DEBUG: local_reply: branch=0, save=0, winner=0 11(5056) DEBUG: tm [t_reply.c:356]: DEBUG: update_totag_set: new totag 11(5056) DEBUG: tm [t_reply.c:1831]: DEBUG: local transaction completed 11(5056) DEBUG: tm [t_hooks.c:288]: DBG: trans=0x7f9767eb1268, callback type 256, id 0 entered 11(5056) DEBUG: dialog [dlg_transfer.c:207]: completed with status 200 11(5056) DEBUG: [parser/parse_to.c:179]: DEBUG: add_param: tag=533cb9e91f4b999cf76861cbb9ed54ed-3bcd 9(5052) DEBUG: [parser/msg_parser.c:612]: SIP Request: 9(5052) DEBUG: [parser/msg_parser.c:614]: method: 9(5052) DEBUG: [parser/msg_parser.c:616]: uri: < sip:2...@10.1.3.15:5061> 9(5052) DEBUG: [parser/msg_parser.c:618]: version: 9(5052) DEBUG: [parser/parse_via.c:1283]: Found param type 232, = ; state=16 9(5052) DEBUG: [parser/parse_via.c:2296]: end of header reached, state=5 9(5052) DEBUG: [parser/msg_parser.c:500]: parse_headers: Via found, flags=2 9(5052) DEBUG: [parser/msg_parser.c:502]: parse_headers: this is the first via 9(5052) DEBUG: [receive.c:137]: After parse_msg... 9(5052) DEBUG: [receive.c:177]: preparing to run routing scripts... 9(5052) DEBUG: sl [sl_funcs.c:335]: to late to be a local ACK! 9(5052) DEBUG: [parser/parse_to.c:179]: DEBUG: add_param: tag=94cf927f9c6eed24i1 9(5052) DEBUG: [parser/parse_to.c:808]: end of header reached, state=29 9(5052) DEBUG: [parser/msg_parser.c:174]: DEBUG: get_hdr_field: [43]; uri=[sip:2...@10.1.2.122 ] 9(5052) DEBUG: [parser/msg_parser.c:176]: DEBUG: to body [ sip:2...@10.1.2.122 ] 9(5052) DEBUG: [parser/msg_parser.c:154]: get_hdr_field: cseq : <10> 9(5052) DEBUG: [parser/msg_parser.c:188]: DEBUG: get_hdr_body : content_length=0 9(5052) DEBUG: [parser/msg_parser.c:90]: found end of header 9(5052) DEBUG: maxfwd [mf_funcs.c:66]: max_forwards header not found! 9(5052) DEBUG: [parser/parse_to.c:179]: DEBUG: add_param: tag=533cb9e91f4b999cf76861cbb9ed54ed-3bcd 9(5052) DEBUG: [parser/parse_to.c:808]: end of header reached, state=29 9(5052) DEBUG: sanity [mod_sanity.c:220]: all sanity checks passed 9(5052) ERROR:
Re: [SR-Users] no Contact in REFER generated with dlg_bridge
Hi, you are right, it has to be the same in the original request only when the final response is a non-2xx (RFC3261, 17.1.1.3). The magic cookie is missing so '0' can not be a valid RFC3261 branch, anyway a '0' value populating a param when it should be a random value looks like a buggy situation. This happens in both 3.0.0 and 3.0.1. Regarding the traces I attached in the previous mail, please, omit the NOTIFY which are being sent to kamailio.org :-), to work this around I replied this NOTIFY (which indicates the state of the REFER processing) from the Kamailio configuration with a 200OK, it works for me. Thanks, feedbacks are welcome Anton 2010/5/25 Klaus Darilion > > > Am 25.05.2010 12:25, schrieb Anton Roman: > > Hi all, >> >> I'm trying to implement a Click2Dial service by using the dlg_bridge >> command from the dialog module. Although it works in this case, I found >> two problems in the scenario and I would like to read your opinion about >> them. >> >> 1) Fisrt problem: the REFER generated by Kamailio doesn't contain a >> contact header. As per RFC 3515, this request should have a Contact >> header. This REFER is not being accepted by a proprietary device. This >> is can be worked around with the append_hf() command from the textops >> module, but I don know if it is a good solution. >> >> 2) The second one arises when the ACK generated by Kamailio, goes >> through Kamailio (caller and calle involved in click2dial are registered >> on the Kamailio server): the branch of the second via header is not >> correctly populated. Its content is '0' when it must be tha same as in >> the INVITE. >> > > AFAIK if the ACK is an ACK to a 2xx response, then the ACK is a new > transaction and should have a new branch id. > > If 0 is a proper branch id is another question (IIRC it is valid with > RFC2543 but not with 3261). > > This is an often raised topic which you can find discussed in the archive. > > regards > Klaus > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
