Re: [SR-Users] pdb module timeouts
On Wednesday 09 February 2011, Thomas Baumann wrote: > I am using the PDB module and server components for number portability. 2 > instances of PDB Server runs on (10.12.19.51/10001/10002), Kamailio on > (10.12.19.21). With a small amount of traffic (-cmax 150 -cps 10 > -callduration 3), where are timeouts: WARNING: pdb [pdb.c:260]: exceeded > timeout while waiting for response. > > One requested number was 307111094, where the module prints out a timeout. > > The funny part is, that I can see the responses at least arriving at the > 10.12.19.21 interface on time. > > Request send: 0,200855 s > Answer received: 0,201027 s > > That are 0,172 ms and far away from a timeout. > > What could be the reason ? Hi Thomas, a bit difficult to say on a first sight.. Maybe some scheduling or load issues on the local machine? I've just checked two production server here, i don't see it so far in the available logs. How much load do you've on the machine? And what kind of timeout value do you specified? > ps. A small change on the server part was done: handle 4 digit carrier > codes. Ah, i see. I guess its not a big change? Regards, Henning ___ 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] Kamailio NOTIFY
Am 11.02.2011 07:57, schrieb Spinov Evgeniy:
> Thank you for detailed explanation, now I've got it, but I'm confused
> about workaround. Really nothing could be done to send phone offline or
> get it online when it's off? For instance to get it online, it's
> possible to emulate false call, with INVITE, for instance.
>
> Have you tried something like that?
Again: There is now way to signal 'offline' in a 'dialog' info - there
is no XML syntax defined for that. But there is 'offline' in 'presence'
info which can be triggered, e.g:
http://www.kamailio.org/docs/modules/3.1.x/modules_k/pua_usrloc.html
klaus
>
> On Fri, 2011-02-11 at 01:28 +0100, Klaus Darilion wrote:
>> Spinov Evgeniy wrote:
>>> On Wed, 2011-02-09 at 16:24 +0100, Klaus Darilion wrote:
>>>
>>> Thank you for the links, especially this one
>>> http://www.kamailio.org/docs/modules/3.1.x/modules_k/pua_dialoginfo.html#id2887055
>>>
>>> I've missed this section while read README. I've fixed that out and made
>>> it working for INVITE requests. I.e. when I'm making a call, status is
>>> displayed normally, and when call is hanged - status is online again.
>>> That works correctly.
>>>
>>> However I cannot get, how to get it working for REGISTER requests, i.e.
>>> when the phone was down and I'm registering - it's not coming online on
>>> SPA until the first call. And when I'm going offline - unregistering,
>>> I'm still online.
>>
>> Don't confuse 'presence' with 'dialog'info events. 'Presence' allows
>> offline/online/away/busy/atlunch/... status of presentities (phones).
>>
>> 'dialog' gives you detailed dialog statistics like idle/busy/ringing
>> with callids/totag/fromtag... so you can for example pick up a call.
>> That's why nothing happens on REGISTER because REGISTER does not create
>> a dialog. There is also no workaround as the 'dialog' event has not
>> states to publish offline/online.
>>
>> regards
>> Klaus
>>
>>> PUBLISH requests are sent, but they are presence type. According to
>>> debug, dialog processing request and assigning hash to it and after
>>> dialog, pua is sending PUBLISH with event presence. pua_dialoginfo never
>>> come up in request.
>>>
>>> Dialog processing is very simple:
>>>
>>> if (is_method("INVITE|REGISTER")) {
>>> dlg_manage();
>>> }
>>>
>>> Somewhy, pua_dialoginfo comes with INVITE request and never comes with
>>> REGISTER.
>>>
>>> Any ideas?
>>>
>>>
Am 09.02.2011 14:56, schrieb Spinov Evgeniy:
> On Wed, 2011-02-09 at 14:47 +0100, Klaus Darilion wrote:
>> Do you see PUBLISH requests with Event: dialog?
>>
>> Note: those will be sent by pua_dialoginfo module to Kamailio itslef,
>> thus will be sent on the loopback interface. You should see them with
>> "ngrep -d any port 5060"
>>
>> klaus
> No, PUBLISH requests with event dialog are not generated. Instead of
> dialog event, presence event is generated, but as for me, it should
> work, as for instance eyeBeam is generating PUBLISH requests itself,
> with event: presence.
>
> You're saying that NOTIFYs with event dialog are empty, cause there are
> not PUBLISH event: dialog?
Yes. The "presence server" is just a relay of the content:
PUBLISH ---> presence server <---SUBSCRIBE/NOTIFY---> client
If dialoginfo is not published into the presence server, the presence
server will send empty NOTIFYs.
There are 2 ways to get the dialoginfo published into the presence
server: either the phone does it (e.g. SNOM phones can do that, eyebeam
only publishes "presence" but not "dialog"info) or Kamailio can PUBLISH
the dialog state. See
http://www.kamailio.org/docs/modules/3.1.x/modules_k/presence_dialoginfo.html
So, make sure that Kamailio will publish the dialoginfo:
http://www.kamailio.org/docs/modules/3.1.x/modules_k/pua_dialoginfo.html#id2887055
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
Re: [SR-Users] Kamailio NOTIFY
Yea, yea, I got that dialog do not have offline and online status. You
mean, that there is no way to tell phone, that extension is offline,
even if it is offline by Kamailio no chance to pass this info to phone
unless it's subscribed for presence event, right?
On Fri, 2011-02-11 at 10:34 +0100, Klaus Darilion wrote:
>
> Am 11.02.2011 07:57, schrieb Spinov Evgeniy:
> > Thank you for detailed explanation, now I've got it, but I'm confused
> > about workaround. Really nothing could be done to send phone offline or
> > get it online when it's off? For instance to get it online, it's
> > possible to emulate false call, with INVITE, for instance.
> >
> > Have you tried something like that?
>
> Again: There is now way to signal 'offline' in a 'dialog' info - there
> is no XML syntax defined for that. But there is 'offline' in 'presence'
> info which can be triggered, e.g:
> http://www.kamailio.org/docs/modules/3.1.x/modules_k/pua_usrloc.html
>
> klaus
>
> >
> > On Fri, 2011-02-11 at 01:28 +0100, Klaus Darilion wrote:
> >> Spinov Evgeniy wrote:
> >>> On Wed, 2011-02-09 at 16:24 +0100, Klaus Darilion wrote:
> >>>
> >>> Thank you for the links, especially this one
> >>> http://www.kamailio.org/docs/modules/3.1.x/modules_k/pua_dialoginfo.html#id2887055
> >>>
> >>> I've missed this section while read README. I've fixed that out and made
> >>> it working for INVITE requests. I.e. when I'm making a call, status is
> >>> displayed normally, and when call is hanged - status is online again.
> >>> That works correctly.
> >>>
> >>> However I cannot get, how to get it working for REGISTER requests, i.e.
> >>> when the phone was down and I'm registering - it's not coming online on
> >>> SPA until the first call. And when I'm going offline - unregistering,
> >>> I'm still online.
> >>
> >> Don't confuse 'presence' with 'dialog'info events. 'Presence' allows
> >> offline/online/away/busy/atlunch/... status of presentities (phones).
> >>
> >> 'dialog' gives you detailed dialog statistics like idle/busy/ringing
> >> with callids/totag/fromtag... so you can for example pick up a call.
> >> That's why nothing happens on REGISTER because REGISTER does not create
> >> a dialog. There is also no workaround as the 'dialog' event has not
> >> states to publish offline/online.
> >>
> >> regards
> >> Klaus
> >>
> >>> PUBLISH requests are sent, but they are presence type. According to
> >>> debug, dialog processing request and assigning hash to it and after
> >>> dialog, pua is sending PUBLISH with event presence. pua_dialoginfo never
> >>> come up in request.
> >>>
> >>> Dialog processing is very simple:
> >>>
> >>> if (is_method("INVITE|REGISTER")) {
> >>> dlg_manage();
> >>> }
> >>>
> >>> Somewhy, pua_dialoginfo comes with INVITE request and never comes with
> >>> REGISTER.
> >>>
> >>> Any ideas?
> >>>
> >>>
> Am 09.02.2011 14:56, schrieb Spinov Evgeniy:
> > On Wed, 2011-02-09 at 14:47 +0100, Klaus Darilion wrote:
> >> Do you see PUBLISH requests with Event: dialog?
> >>
> >> Note: those will be sent by pua_dialoginfo module to Kamailio itslef,
> >> thus will be sent on the loopback interface. You should see them with
> >> "ngrep -d any port 5060"
> >>
> >> klaus
> > No, PUBLISH requests with event dialog are not generated. Instead of
> > dialog event, presence event is generated, but as for me, it should
> > work, as for instance eyeBeam is generating PUBLISH requests itself,
> > with event: presence.
> >
> > You're saying that NOTIFYs with event dialog are empty, cause there are
> > not PUBLISH event: dialog?
> Yes. The "presence server" is just a relay of the content:
>
>
>
> PUBLISH ---> presence server <---SUBSCRIBE/NOTIFY---> client
>
> If dialoginfo is not published into the presence server, the presence
> server will send empty NOTIFYs.
>
> There are 2 ways to get the dialoginfo published into the presence
> server: either the phone does it (e.g. SNOM phones can do that, eyebeam
> only publishes "presence" but not "dialog"info) or Kamailio can PUBLISH
> the dialog state. See
> http://www.kamailio.org/docs/modules/3.1.x/modules_k/presence_dialoginfo.html
>
> So, make sure that Kamailio will publish the dialoginfo:
> http://www.kamailio.org/docs/modules/3.1.x/modules_k/pua_dialoginfo.html#id2887055
>
> 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
Re: [SR-Users] TLS Support
Thanks a lot :-) -Ursprüngliche Nachricht- Von: Klaus Darilion [mailto:klaus.mailingli...@pernau.at] Gesendet: Donnerstag, 10. Februar 2011 19:19 An: Bernhard Suttner Cc: sr-users@lists.sip-router.org Betreff: Re: [SR-Users] TLS Support Bernhard Suttner wrote: > Hi, > > how could I compile the TLS module and only the TLS module - not the other > sources. cd modules/tls make regards klaus > > BTW: The documentation within the http://www.kamailio.org/docs/tls.html is > not up-to-date. > > Thanks in advance. > > Best regards, > Bernhard > > > > ___ > 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 ___ 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
[SR-Users] NAT, TLS and location table
Hi, I am using TLS and recognize the following problem: The TLS connection are build up successfully but the natping (natping_interval = 10) does not send small dummy packets to the phones. The phones are behind a firewall with NAT. Registered phones with NAT but UDP do work correctly. They are getting the natping every 10 seconds. After 120 seconds (should be the tcp_connection_timeout) kamailio does send a FIN to the TLS phone to close the TLS connection. Should I increase the tcp_connection_timeout to a value bigger than the registration timeout? I thought I do not need that, because of the natping_interval. Is it maybe better to use a SIP-Options Ping instead of the small dummy packets? I would prefer the dummy packets because they are much smaller. BTW: Kamailio 3.1.1 and snom360 with latest v8 firmware. Thanks in advance! Best regards, Bernhard ___ 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] NAT, TLS and location table
Am 11.02.2011 12:15, schrieb Bernhard Suttner: > Hi, > > I am using TLS and recognize the following problem: > > The TLS connection are build up successfully but the natping > (natping_interval = 10) does not send small dummy packets to the > phones. The phones are behind a firewall with NAT. Registered phones > with NAT but UDP do work correctly. They are getting the natping > every 10 seconds. After 120 seconds (should be the > tcp_connection_timeout) kamailio does send a FIN to the TLS phone to > close the TLS connection. IIRC the keep-alive code in nathelper module sends CRLF only on UDP. IMO it would be nice if it sends it also on TCP/TLS connections, at least as a config option. Of course the code should also take care of not setting up a new TCP connection if the old one is gone. I once have seen a client which was confused by the CRLF and then closes the TCP connection, so there might be other problems as well. Of course the proper solution (IETF view) is that the clients sends keep-alive (SIP outbound RFC). > Should I increase the tcp_connection_timeout to a value bigger than > the registration timeout? I thought I do not need that, because of > the natping_interval. Is it maybe better to use a SIP-Options Ping > instead of the small dummy packets? I would prefer the dummy packets > because they are much smaller. http://www.kamailio.org/dokuwiki/doku.php/install:1.5.x-to-3.0.0#tcp_connection_lifetime http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#tcp_keepalive and http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#set_forward_no_connect (to be used after lookup()) might be interesting too. 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
Re: [SR-Users] NAT, TLS and location table
Hi, thanks for you response. Do you think that kamailio does send sip-options-ping within TCP/TLS (instead of sending the dummy packets)? Best regards, Bernhard -Ursprüngliche Nachricht- Von: Klaus Darilion [mailto:klaus.mailingli...@pernau.at] Gesendet: Freitag, 11. Februar 2011 12:30 An: Bernhard Suttner Cc: sr-users@lists.sip-router.org Betreff: Re: [SR-Users] NAT, TLS and location table Am 11.02.2011 12:15, schrieb Bernhard Suttner: > Hi, > > I am using TLS and recognize the following problem: > > The TLS connection are build up successfully but the natping > (natping_interval = 10) does not send small dummy packets to the > phones. The phones are behind a firewall with NAT. Registered phones > with NAT but UDP do work correctly. They are getting the natping > every 10 seconds. After 120 seconds (should be the > tcp_connection_timeout) kamailio does send a FIN to the TLS phone to > close the TLS connection. IIRC the keep-alive code in nathelper module sends CRLF only on UDP. IMO it would be nice if it sends it also on TCP/TLS connections, at least as a config option. Of course the code should also take care of not setting up a new TCP connection if the old one is gone. I once have seen a client which was confused by the CRLF and then closes the TCP connection, so there might be other problems as well. Of course the proper solution (IETF view) is that the clients sends keep-alive (SIP outbound RFC). > Should I increase the tcp_connection_timeout to a value bigger than > the registration timeout? I thought I do not need that, because of > the natping_interval. Is it maybe better to use a SIP-Options Ping > instead of the small dummy packets? I would prefer the dummy packets > because they are much smaller. http://www.kamailio.org/dokuwiki/doku.php/install:1.5.x-to-3.0.0#tcp_connection_lifetime http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#tcp_keepalive and http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#set_forward_no_connect (to be used after lookup()) might be interesting too. 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
[SR-Users] handle_new_connect ... Too many open files
Hi, today during two hours kamailio made 2G of a syslog messages. This message was repeated for 10 000 000 times. /sbin/kamailio[24272]: ERROR: [tcp_main.c:3959]: WARNING: handle_new_connect: error while accepting connection(24): Too many open files It was preceded by following error. /sbin/kamailio[24265]: ERROR: [tcp_read.c:269]: error reading: Connection reset by peer (104) /sbin/kamailio[24265]: ERROR: [tcp_read.c:882]: ERROR: tcp_read_req: error reading Finally it stopped without any given reason. I'm using kamailio 3.1.0 (i386/linux) 1e204f, callcontrol 2.0.11 and clustered mysql. Was this some kind of attack, bug, error, misconfiguration or what? Thank for answer, Efelin ___ 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
[SR-Users] [Kamailio-Users] Rewrite $tU
>Hello,
>with the latest version there are alternatives you can use:
>> On 12/10/09 5:06 PM, David wrote:
>> Hey,
>>
>> I won't pretend to be an expert in Kamailio, someone will probably
>> suggest a better way. But here is how I rewrote my SIP packet's TO
>> header before relaying it to the next hop :
>>
>> # Rewrite RURI
>> avp_printf("$rU", "prefix_$rU");
>$rU = "prefix_" + $rU;
>>
>> # Remove existing header
>> remove_hf("To") ;
>>
>> # Add new header which is copied from RURI
>> insert_hf("To: $ru\r\n", "From");
>you can do in one step, so you avoid operations on r-uri:
>insert_hf("To: sip:prefix_$rU@$rd\r\n", "From");
>>
>>
>> DISCLAIMER : Several threads have said that changing the TO header
is
>>a bad idea, so I only recommend using this as a last resort.
>If devices are RFC3261 (SIP 2.0), then it is ok. If there are SIP 1.0
>devices, then you have to preserve To/From header.
>For the future, I would add options to change the From/To values via
>pseudo-variables. It is the admin to decide to use it or not -- now
>people need and do workarounds with subst or append_hf().
>Cheers,
>Daniel
I use Kamailio 3.0.3, and tried to use both of methods, i.e. insert_ft()
and reassigning pseudo variable $rU and all mentioned in this topic.
However, handle_subscribe() and dlg_manage() somewhy uses unmodified
packet.
Is there any workaround to handle $rU or $tU overwrites that for
pua_dialoginfo module?
I'm doing it like that:
$var(orig_uri) = $rU;
$rU = $(fU{re.subst,/(.*)_(.*)/\1/}) + "_" + $rU;
if (is_method("INVITE")) {
dlg_manage();
}
if (is_method("SUBSCRIBE")) {
handle_subscribe();
}
$rU = $var(orig_uri);
However, according to debug messages, NOTIFY's which are coming just
after INVITE are still without prefixes, but packets on Asterisk, which
is after Kamailio, are coming modified.
Please, advice.
>
> David
>
>
>
>
>
> David a écrit :
>> Hey,
>>
>> I do understand that normally the TO header should not be written, my
>> problem is that I am using the presence_dialoginfo module which uses
the
>> TO header and not the RURI, which means that in order to tell the
>> difference between customer A's extension 101 and Customer B's
extension
>> 101, I rewrite the TO header to add context.
>>
>> This is actually the ame problem that I started discussing here :
>> http://lists.kamailio.org/pipermail/users/2009-August/024316.html
>>
>> Trouble is I have not had time to work on this since then.
>>
>> Thanks,
>>
>> David
>>
>> Olle E. Johansson a écrit :
>>> 10 dec 2009 kl. 15.04 skrev Iñaki Baz Castillo:
>>>
>>>
El Jueves, 10 de Diciembre de 2009, David escribió:
> Hey,
>
> I need to rewrite the $tU variable on a packet before it is
> relayed. It
> is ok if the change is only on the relayed packet and the $tU
> variable
> change. The important thing is that I modify the To header, it
seems
> that rewritting $tU would be the easiest.
$tU is not writable, but just readable.
If you want to change the "To" header you should do some "dirty"
replacing operation (see textops module).
>>>
>>> This is propably something we need to change and make the To and
>>> From headers writable.
>>> It's not dirty to change them any more.
>>>
>>> David: In the original SIP 1.0 protocol the To/From headers was
part
>>> of the dialog identification, thus you where not allowed to change
>>> them in a proxy. THis was kept in RFC3261 - sip v2 - but has been
>>> removed in an additional RFC a short while ago (seen from SIP
history).
>>>
>>> Regards,
>>> /O
>>> ___
>>> Kamailio (OpenSER) - Users mailing list
>>> Users at lists.kamailio.org
>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> ___
>> Kamailio (OpenSER) - Users mailing list
>> Users at lists.kamailio.org
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>
>
> ___
> Kamailio (OpenSER) - Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/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-user
[SR-Users] Change transport=tls within Contact Header
Hi, is there a function to change the transport field within the Contact Header? t_relay does relay it to the UDP port of the PBX but the transport within the Contact Header is still set to TLS. Later, the PBX does try to establish a TLS connection. The idea is now, that kamailio does set the transport of the Contact Header to UDP. Another possible way would to be, that I use the re.subst method but maybe there is a special function for that. Thanks in advance. Best regards, Bernhard ___ 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] pdb module timeouts
Hello Henning, the load I have on one machine is about 10 cps max. The timeout is configured to the standard value of 50ms. I the logs I can see that the response times are not continuous. Feb 11 17:28:34 m-lab-prx-as-2 /openser/sbin/kamailio[7609]: INFO: pdb [pdb.c:290]: got an answer in 35.95 ms Feb 11 17:28:34 m-lab-prx-as-2 /openser/sbin/kamailio[7607]: INFO: pdb [pdb.c:290]: got an answer in 0.201000 ms Feb 11 17:28:38 m-lab-prx-as-2 /openser/sbin/kamailio[7609]: INFO: pdb [pdb.c:290]: got an answer in 0.626000 ms Feb 11 17:28:38 m-lab-prx-as-2 /openser/sbin/kamailio[7605]: INFO: pdb [pdb.c:290]: got an answer in 41.026000 ms Feb 11 17:28:38 m-lab-prx-as-2 /openser/sbin/kamailio[7607]: INFO: pdb [pdb.c:290]: got an answer in 29.807000 ms Feb 11 17:28:38 m-lab-prx-as-2 /openser/sbin/kamailio[7609]: INFO: pdb [pdb.c:290]: got an answer in 0.32 ms Feb 11 17:28:38 m-lab-prx-as-2 /openser/sbin/kamailio[7607]: INFO: pdb [pdb.c:290]: got an answer in 0.173000 ms I will do a fallback to the original source and check it again. Maybe there is something from with my modifications. thanks, Thomas -Ursprüngliche Nachricht- Von: "Henning Westerholt" Gesendet: 11.02.2011 09:33:05 An: sr-users@lists.sip-router.org Betreff: Re: [SR-Users] pdb module timeouts On Wednesday 09 February 2011, Thomas Baumann wrote: > I am using the PDB module and server components for number portability. 2 > instances of PDB Server runs on (10.12.19.51/10001/10002), Kamailio on > (10.12.19.21). With a small amount of traffic (-cmax 150 -cps 10 > -callduration 3), where are timeouts: WARNING: pdb [pdb.c:260]: exceeded > timeout while waiting for response. > > One requested number was 307111094, where the module prints out a timeout. > > The funny part is, that I can see the responses at least arriving at the > 10.12.19.21 interface on time. > > Request send: 0,200855 s > Answer received: 0,201027 s > > That are 0,172 ms and far away from a timeout. > > What could be the reason ? Hi Thomas, a bit difficult to say on a first sight.. Maybe some scheduling or load issues on the local machine? I've just checked two production server here, i don't see it so far in the available logs. How much load do you've on the machine? And what kind of timeout value do you specified? > ps. A small change on the server part was done: handle 4 digit carrier > codes. Ah, i see. I guess its not a big change? Regards, Henning ___ NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://produkte.web.de/go/webdefreephone ___ 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
[SR-Users] Error running kamailio 3.1.0
Hi, I have compiled kamailio 3.1.0 without any error and I having this error when running kamailio: ERROR: [sr_module.c:523]: ERROR: load_module: could not open module : /usr/local/lib/kamailio/modules_k/sl.so: undefined symbol: fm_malloc Any will be appreciated. Regards, Lucas ___ 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] After upgrade from openser 1.3.4 to kamailio 1.5.5 the same crash set
Here is it with MEMDBG=1
--
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/openser/openser.pid -m 32 -u openser -g op'.
Program terminated with signal 6, Aborted.
#0 0x0039d8c30265 in raise () from /lib64/libc.so.6
(gdb) backtrace
#0 0x0039d8c30265 in raise () from /lib64/libc.so.6
#1 0x0039d8c31d10 in abort () from /lib64/libc.so.6
#2 0x0046c397 in qm_debug_frag (qm=0x733c00, f=0x7ca950) at
mem/q_malloc.c:137
#3 0x0046d99a in qm_free (qm=0x733c00, p=0x7ca980,
file=0x4e4d30 "parser/digest/digest.c", func=0x4e4da0
"free_credentials", line=95)
at mem/q_malloc.c:439
#4 0x00495fac in free_credentials (_b=0x2ba07046a7b8) at
parser/digest/digest.c:95
#5 0x00471a36 in clean_hdr_field (hf=0x2ba07046a788) at
parser/hf.c:116
#6 0x2ba06cec58de in clean_msg_clone (msg=0x2ba0704697b8,
min=0x2ba0704697b8, max=0x2ba07046add0) at sip_msg.h:54
#7 0x2ba06cec57b7 in run_trans_callbacks (type=2,
trans=0x2ba07045b3f0, req=0x2ba0704697b8, rpl=0x7c0eb8, code=200) at
t_hooks.c:245
#8 0x2ba06cecc39d in t_reply_matching (p_msg=0x7c0eb8,
p_branch=0x7fff8a7202c8) at t_lookup.c:888
#9 0x2ba06cecc997 in t_check (p_msg=0x7c0eb8,
param_branch=0x7fff8a7202c8) at t_lookup.c:964
#10 0x2ba06cedb79b in reply_received (p_msg=0x7c0eb8) at t_reply.c:1395
#11 0x0041c6db in forward_reply (msg=0x7c0eb8) at forward.c:576
#12 0x0043ccf0 in receive_msg (
buf=0x712980 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
XXX.XX.XXX.13;branch=z9hG4bKb01c.8ffe0f62.0;received=XXX.XX.XXX.13\r\nVia:
SIP/2.0/UDP
XXX.XX.XXX.236:5060;received=XXX.XX.XXX.236;branch=z9hG4bK20b12a8d;rport=5060\r\nRec"...,
len=576, rcv_info=0x7fff8a720420) at receive.c:212
#13 0x004692e3 in udp_rcv_loop () at udp_server.c:449
#14 0x00420ecb in main_loop () at main.c:774
#15 0x00422e0f in main (argc=11, argv=0x7fff8a7206a8) at main.c:1321
--
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/openser/openser.pid -m 32 -u openser -g op'.
Program terminated with signal 6, Aborted.
#0 0x0039d8c30265 in raise () from /lib64/libc.so.6
(gdb) backtrace
#0 0x0039d8c30265 in raise () from /lib64/libc.so.6
#1 0x0039d8c31d10 in abort () from /lib64/libc.so.6
#2 0x0046c397 in qm_debug_frag (qm=0x733c00, f=0x83a818) at
mem/q_malloc.c:137
#3 0x0046d99a in qm_free (qm=0x733c00, p=0x83a848,
file=0x4e4d30 "parser/digest/digest.c", func=0x4e4da0
"free_credentials", line=95)
at mem/q_malloc.c:439
#4 0x00495fac in free_credentials (_b=0x2b95e9de8758) at
parser/digest/digest.c:95
#5 0x00471a36 in clean_hdr_field (hf=0x2b95e9de8728) at
parser/hf.c:116
#6 0x2b95e687e8de in clean_msg_clone (msg=0x2b95e9de7758,
min=0x2b95e9de7758, max=0x2b95e9de8d70) at sip_msg.h:54
#7 0x2b95e687e7b7 in run_trans_callbacks (type=2,
trans=0x2b95e9fe5150, req=0x2b95e9de7758, rpl=0x7c0eb8, code=200) at
t_hooks.c:245
#8 0x2b95e688539d in t_reply_matching (p_msg=0x7c0eb8,
p_branch=0x7fff77e144b8) at t_lookup.c:888
#9 0x2b95e6885997 in t_check (p_msg=0x7c0eb8,
param_branch=0x7fff77e144b8) at t_lookup.c:964
#10 0x2b95e689479b in reply_received (p_msg=0x7c0eb8) at t_reply.c:1395
#11 0x0041c6db in forward_reply (msg=0x7c0eb8) at forward.c:576
#12 0x0043ccf0 in receive_msg (
buf=0x712980 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
XXX.XX.XXX.13;branch=z9hG4bK2cb3.224aa3e4.0;received=XXX.XX.XXX.13\r\nVia:
SIP/2.0/UDP
XXX.XX.XXX.236:5060;received=XXX.XX.XXX.236;branch=z9hG4bK3ca41325;rport=5060\r\nRec"...,
len=576, rcv_info=0x7fff77e14610) at receive.c:212
#13 0x004692e3 in udp_rcv_loop () at udp_server.c:449
#14 0x00420ecb in main_loop () at main.c:774
#15 0x00422e0f in main (argc=11, argv=0x7fff77e14898) at main.c:1321
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/openser/openser.pid -m 32 -u openser -g op'.
Program terminated with signal 11, Segmentation fault.
#0 0x0046bf7b in add_avp_galias_str (alias_definition=0x46de56
"") at usr_avp.c:680
680 LM_ERR("parse error in <%s> around pos %ld\n",
(gdb) backtrace
#0 0x0046bf7b in add_avp_galias_str (alias_definition=0x46de56
"") at usr_avp.c:680
#1 0x in ?? ()
On 02/10/2011 09:14 AM, Daniel-Constantin Mierla wrote:
On 2/10/11 8:12 AM, Andrew O. Zhukov wrote:
Couple month ago I sent whole set of crash-es from 1.3.4 to this
maillist. Nobody respond me.
Probably they were forgotten in the history, if most of devs were
offline at the moment you sent. Do you have a link to the thread, it may
help reading what you sent at that time, as well.
_
Re: [SR-Users] handle_new_connect ... Too many open files
On Friday 11 February 2011, Efelin Novak wrote: > today during two hours kamailio made 2G of a syslog messages. This message > was repeated for 10 000 000 times. > > /sbin/kamailio[24272]: ERROR: [tcp_main.c:3959]: WARNING: > handle_new_connect: error while accepting connection(24): Too many open > files > > It was preceded by following error. > > /sbin/kamailio[24265]: ERROR: [tcp_read.c:269]: error reading: > Connection reset by peer (104) /sbin/kamailio[24265]: ERROR: > [tcp_read.c:882]: ERROR: tcp_read_req: error reading > > Finally it stopped without any given reason. > > I'm using kamailio 3.1.0 (i386/linux) 1e204f, callcontrol 2.0.11 and > clustered mysql. > > Was this some kind of attack, bug, error, misconfiguration or what? Hi Efelin, could be an attack, but maybe its just an small misconfiguration of your server? Have you tried to increase the "ulimit -n" and "/proc/sys/kernel/file- max" settings? Then your box should be able to open more file handles. Cheers, Henning ___ 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] pdb module timeouts
On Friday 11 February 2011, Thomas Baumann wrote: > the load I have on one machine is about 10 cps max. The timeout is > configured to the standard value of 50ms. I the logs I can see that the > response times are not continuous. > Feb 11 17:28:34 m-lab-prx-as-2 /openser/sbin/kamailio[7609]: INFO: pdb > [pdb.c:290]: got an answer in 35.95 ms > Feb 11 17:28:34 m-lab-prx-as-2 /openser/sbin/kamailio[7607]: INFO: pdb > [pdb.c:290]: got an answer in 0.201000 ms Hi Thomas, this is not much load, and a long timeout. Maybe its something special about the used scheduler, or some other process that causes delays? The response times looks indeed somehow strange. Cheers, Henning ___ 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] NAT, TLS and location table
Am 11.02.2011 13:15, schrieb Bernhard Suttner: > Hi, > > thanks for you response. Do you think that kamailio does send > sip-options-ping within TCP/TLS (instead of sending the dummy packets)? I don't know, I never tried it. 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
Re: [SR-Users] [Kamailio-Users] Rewrite $tU
Am 11.02.2011 14:51, schrieb Spinov Evgeniy:
>> Hello,
>
>> with the latest version there are alternatives you can use:
>
>>> On 12/10/09 5:06 PM, David wrote:
>>> Hey,
>>>
>>> I won't pretend to be an expert in Kamailio, someone will probably
>>> suggest a better way. But here is how I rewrote my SIP packet's TO
>>> header before relaying it to the next hop :
>>>
>>> # Rewrite RURI
>>> avp_printf("$rU", "prefix_$rU");
>
>> $rU = "prefix_" + $rU;
>
>>>
>>> # Remove existing header
>>> remove_hf("To") ;
>>>
>>> # Add new header which is copied from RURI
>>> insert_hf("To: $ru\r\n", "From");
>
>> you can do in one step, so you avoid operations on r-uri:
>
>> insert_hf("To: sip:prefix_$rU@$rd\r\n", "From");
>
>>>
>>>
>>> DISCLAIMER : Several threads have said that changing the TO header
> is
>>> a bad idea, so I only recommend using this as a last resort.
>
>> If devices are RFC3261 (SIP 2.0), then it is ok. If there are SIP 1.0
>> devices, then you have to preserve To/From header.
>
>> For the future, I would add options to change the From/To values via
>> pseudo-variables. It is the admin to decide to use it or not -- now
>> people need and do workarounds with subst or append_hf().
>
>> Cheers,
>> Daniel
>
> I use Kamailio 3.0.3, and tried to use both of methods, i.e. insert_ft()
> and reassigning pseudo variable $rU and all mentioned in this topic.
> However, handle_subscribe() and dlg_manage() somewhy uses unmodified
> packet.
Yes, most functions do not see message manipulation as the manipulations
are applied just before sending out the message again. So the changes
are applied after the functions.
Workaround 1: loop the message to Kamailio again
Workaround 2: Since Kamailio 3.1 you can use msg_apply_changes():
http://www.kamailio.org/docs/modules/3.1.x/modules/textopsx.html#msg_apply_changes
But note, this causes the message to be changed and reparsed, thus it
may be a performance killer (double processing time for message parsing)
klaus
>
> Is there any workaround to handle $rU or $tU overwrites that for
> pua_dialoginfo module?
>
> I'm doing it like that:
>
> $var(orig_uri) = $rU;
> $rU = $(fU{re.subst,/(.*)_(.*)/\1/}) + "_" + $rU;
> if (is_method("INVITE")) {
> dlg_manage();
> }
>
>
> if (is_method("SUBSCRIBE")) {
> handle_subscribe();
> }
>
>
> $rU = $var(orig_uri);
>
> However, according to debug messages, NOTIFY's which are coming just
> after INVITE are still without prefixes, but packets on Asterisk, which
> is after Kamailio, are coming modified.
>
> Please, advice.
>
>>
>> David
>>
>>
>>
>>
>>
>> David a écrit :
>>> Hey,
>>>
>>> I do understand that normally the TO header should not be written, my
>>> problem is that I am using the presence_dialoginfo module which uses
> the
>>> TO header and not the RURI, which means that in order to tell the
>>> difference between customer A's extension 101 and Customer B's
> extension
>>> 101, I rewrite the TO header to add context.
>>>
>>> This is actually the ame problem that I started discussing here :
>>> http://lists.kamailio.org/pipermail/users/2009-August/024316.html
>>>
>>> Trouble is I have not had time to work on this since then.
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> Olle E. Johansson a écrit :
10 dec 2009 kl. 15.04 skrev Iñaki Baz Castillo:
> El Jueves, 10 de Diciembre de 2009, David escribió:
>> Hey,
>>
>> I need to rewrite the $tU variable on a packet before it is
>> relayed. It
>> is ok if the change is only on the relayed packet and the $tU
>> variable
>> change. The important thing is that I modify the To header, it
> seems
>> that rewritting $tU would be the easiest.
> $tU is not writable, but just readable.
> If you want to change the "To" header you should do some "dirty"
> replacing operation (see textops module).
This is propably something we need to change and make the To and
From headers writable.
It's not dirty to change them any more.
David: In the original SIP 1.0 protocol the To/From headers was
> part
of the dialog identification, thus you where not allowed to change
them in a proxy. THis was kept in RFC3261 - sip v2 - but has been
removed in an additional RFC a short while ago (seen from SIP
> history).
Regards,
/O
___
Kamailio (OpenSER) - Users mailing list
Users at lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
Re: [SR-Users] Change transport=tls within Contact Header
Am 11.02.2011 15:21, schrieb Bernhard Suttner: > Hi, > > is there a function to change the transport field within the Contact > Header? t_relay does relay it to the UDP port of the PBX but the > transport within the Contact Header is still set to TLS. Later, the > PBX does try to establish a TLS connection. > > The idea is now, that kamailio does set the transport of the Contact > Header to UDP. Another possible way would to be, that I use the > re.subst method but maybe there is a special function for that. If the proxy does record routing, then the PBX has to use the Record-Route header for routing of in-dialog messages, not the Contact header. Maybe is your PBX buggy. Anyway, if the PBX is buggy and you have to solve it in the proxy, you have to use textops module to change the Contact header. Note: manual manipulation might conflict with manipulations from nathelper module and thus you may end up with a malformed contact header. regards klasu ___ 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] Kamailio 1.5.4 and beyond - mhomed issue under Linux
Hi all, I checked the GIT repository and noticed that there was a patch in forward.c for this issue. Looks like it was done 11/4/2010. Two questions: 1) Is there any reason that patch didn't make it into Kamailio 3.1.2 ? 2) Any reason I shouldn't apply that patck to my 1.5.4 release? Thanks, Sean O'Donnell Senior Engineer uReach Technologies, Inc. On Thu, 10 Feb 2011, Sean O'Donnell (skodonn...@ureach.com) wrote: Hi all, I just started deploying Kamailio release 1.5.4, and I think there's an issue with how Kamailio identifies an outgoing interface when mhomed is enabled under Linux. I use Kamailio as a call distributor/proxy between a soft-switch/SBC and a voicemail platform. It runs on a CentOS 5.3 (Linux 2.6 kernel) host with two network interfaces and is configured such that it listens on both interfaces. One interface (public interface) handles traffic with the SBC, the other (private interface) handles with the VM platform. The 'mhomed' option is enabled. After upgrading from 1.5.3 to 1.5.4, I started noticing problems with UDP packets coming out of the public interface. After looking at some ngrep captures on that interface, I noticed that some packets had the source IP address of the private interface and also had Record-Route and Via headers for the private interface only - no headers for the public interface were there. Usually when I see the wrong source IP in a UDP packet, it's an issue with how routes are set up on the host. However, I had our network engineer double check them, and they seem fine (no ambiguous routes). The fact that I captured these messages on the public interface also indicates to me that the kernel is routing the message correctly. The missing Record-Route and Via for the public interface, however, lead me to believe that the proxy didn't correctly identify the outgoing interface in the first place. After looking at the ChangeLog for 1.5.4, I noticed that the some new logic was put in to improve performance when mhomed is enabled (r5971) in forward.c, and I think this is the issue. As I understand it, prior to 1.5.4, when mhomed was enabled, Kamailio determined the outgoing interface by creating a temporary UDP socket, invoking connect() on the socket with the packet destination, then checking the source IP of the socket that the kernel assigned using getsockname(). After the source address was determined, the temp socket was closed closed. As of 1.5.4, this was modified to reuse the temporary socket and just re-invoking connect() with a new destination address. The problem with the enhancement is that Linux (again, at least in the 2.6 kernels I'm using) doesn't seem to rebind a new source address to the socket when connect() is called more than once on a UDP socket. Instead, it keeps the original one, and thus the wrong interface is assumed. I wrote a small program to confirm this - basically creates a UDP socket, calls connect()/getsockname() multiple times using different destination addresses. I ran it on several 2.6 kernels, including Centos4.x and Centos5. The result was always that the source address of the socket wasn't changed after the first connect(), regardless of the destination address. The only way I could get it work as required was to first do a connect() using a zero'd out AF_UNSPEC address before doing the connect() to the remote address. I also ran it on Solaris and it worked. Go figure. I've downloaded the latest stable release (3.1.2) but I think the issue is still there, and I don't see anything in the user groups that addresses this. Any help would be appreciated. Thanks, Sean ___ 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 ___ 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] pdb module timeouts
Henning Westerholt writes: > > ps. A small change on the server part was done: handle 4 digit carrier > > codes. > > Ah, i see. I guess its not a big change? i have done the same change. perhaps it would make sense to make the module a bit more flexible in terms of length of carrier code. -- juha ___ 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
[SR-Users] kamailio 1.5.5 crashes continue
Core was generated by `/usr/local/sbin/kamailio -P /var/run/openser/openser.pid -m 32 -u openser -g op'. Program terminated with signal 6, Aborted. #0 0x0039d8c30265 in raise () from /lib64/libc.so.6 (gdb) backtrace #0 0x0039d8c30265 in raise () from /lib64/libc.so.6 #1 0x0039d8c31d10 in abort () from /lib64/libc.so.6 #2 0x0046c397 in qm_debug_frag (qm=0x733c00, f=0x841420) at mem/q_malloc.c:137 #3 0x0046d99a in qm_free (qm=0x733c00, p=0x841450, file=0x4e4d30 "parser/digest/digest.c", func=0x4e4da0 "free_credentials", line=95) at mem/q_malloc.c:439 #4 0x00495fac in free_credentials (_b=0x2b875404a130) at parser/digest/digest.c:95 #5 0x00471a36 in clean_hdr_field (hf=0x2b875404a100) at parser/hf.c:116 #6 0x2b8750ab78de in clean_msg_clone (msg=0x2b8754049130, min=0x2b8754049130, max=0x2b875404a748) at sip_msg.h:54 #7 0x2b8750ab77b7 in run_trans_callbacks (type=2, trans=0x2b8754057ec0, req=0x2b8754049130, rpl=0x7c0eb8, code=200) at t_hooks.c:245 #8 0x2b8750abe39d in t_reply_matching (p_msg=0x7c0eb8, p_branch=0x7fffbe5d11e8) at t_lookup.c:888 #9 0x2b8750abe997 in t_check (p_msg=0x7c0eb8, param_branch=0x7fffbe5d11e8) at t_lookup.c:964 #10 0x2b8750acd79b in reply_received (p_msg=0x7c0eb8) at t_reply.c:1395 #11 0x0041c6db in forward_reply (msg=0x7c0eb8) at forward.c:576 #12 0x0043ccf0 in receive_msg ( buf=0x712980 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP XXX.XX.XXX.13;branch=z9hG4bK8aa9.93e271f1.0;received=XXX.XX.XXX.13\r\nVia: SIP/2.0/UDP XXX.XX.XXX.236:5060;received=XXX.XX.XXX.236;branch=z9hG4bK37dacff3;rport=5060\r\nRec"..., len=576, rcv_info=0x7fffbe5d1340) at receive.c:212 #13 0x004692e3 in udp_rcv_loop () at udp_server.c:449 #14 0x00420ecb in main_loop () at main.c:774 #15 0x00422e0f in main (argc=11, argv=0x7fffbe5d15c8) at main.c:1321 (gdb) q [root@ tmp]# openser -V version: kamailio 1.5.5-notls (x86_64/linux) flags: STATISTICS, EXTRA_DEBUG, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4194304 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 5608 2009-02-13 16:48:17Z henningw $ main.c compiled on 09:42:37 Feb 10 2011 with gcc 4.1.2 Andrew. ___ 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] After upgrade from openser 1.3.4 to kamailio 1.5.5 the same crash set
On 2/11/11 6:23 PM, Andrew O. Zhukov wrote:
Here is it with MEMDBG=1
Did you get in syslog any error (bug) message mentioning overwriting
tail/head for memory operations? If yes, send the syslog messages here.
I will try to look over it soon, being offline for some traveling...
Cheers,
Daniel
--
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/openser/openser.pid -m 32 -u openser -g op'.
Program terminated with signal 6, Aborted.
#0 0x0039d8c30265 in raise () from /lib64/libc.so.6
(gdb) backtrace
#0 0x0039d8c30265 in raise () from /lib64/libc.so.6
#1 0x0039d8c31d10 in abort () from /lib64/libc.so.6
#2 0x0046c397 in qm_debug_frag (qm=0x733c00, f=0x7ca950) at
mem/q_malloc.c:137
#3 0x0046d99a in qm_free (qm=0x733c00, p=0x7ca980,
file=0x4e4d30 "parser/digest/digest.c", func=0x4e4da0
"free_credentials", line=95)
at mem/q_malloc.c:439
#4 0x00495fac in free_credentials (_b=0x2ba07046a7b8) at
parser/digest/digest.c:95
#5 0x00471a36 in clean_hdr_field (hf=0x2ba07046a788) at
parser/hf.c:116
#6 0x2ba06cec58de in clean_msg_clone (msg=0x2ba0704697b8,
min=0x2ba0704697b8, max=0x2ba07046add0) at sip_msg.h:54
#7 0x2ba06cec57b7 in run_trans_callbacks (type=2,
trans=0x2ba07045b3f0, req=0x2ba0704697b8, rpl=0x7c0eb8, code=200) at
t_hooks.c:245
#8 0x2ba06cecc39d in t_reply_matching (p_msg=0x7c0eb8,
p_branch=0x7fff8a7202c8) at t_lookup.c:888
#9 0x2ba06cecc997 in t_check (p_msg=0x7c0eb8,
param_branch=0x7fff8a7202c8) at t_lookup.c:964
#10 0x2ba06cedb79b in reply_received (p_msg=0x7c0eb8) at
t_reply.c:1395
#11 0x0041c6db in forward_reply (msg=0x7c0eb8) at forward.c:576
#12 0x0043ccf0 in receive_msg (
buf=0x712980 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
XXX.XX.XXX.13;branch=z9hG4bKb01c.8ffe0f62.0;received=XXX.XX.XXX.13\r\nVia:
SIP/2.0/UDP
XXX.XX.XXX.236:5060;received=XXX.XX.XXX.236;branch=z9hG4bK20b12a8d;rport=5060\r\nRec"...,
len=576, rcv_info=0x7fff8a720420) at receive.c:212
#13 0x004692e3 in udp_rcv_loop () at udp_server.c:449
#14 0x00420ecb in main_loop () at main.c:774
#15 0x00422e0f in main (argc=11, argv=0x7fff8a7206a8) at
main.c:1321
--
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/openser/openser.pid -m 32 -u openser -g op'.
Program terminated with signal 6, Aborted.
#0 0x0039d8c30265 in raise () from /lib64/libc.so.6
(gdb) backtrace
#0 0x0039d8c30265 in raise () from /lib64/libc.so.6
#1 0x0039d8c31d10 in abort () from /lib64/libc.so.6
#2 0x0046c397 in qm_debug_frag (qm=0x733c00, f=0x83a818) at
mem/q_malloc.c:137
#3 0x0046d99a in qm_free (qm=0x733c00, p=0x83a848,
file=0x4e4d30 "parser/digest/digest.c", func=0x4e4da0
"free_credentials", line=95)
at mem/q_malloc.c:439
#4 0x00495fac in free_credentials (_b=0x2b95e9de8758) at
parser/digest/digest.c:95
#5 0x00471a36 in clean_hdr_field (hf=0x2b95e9de8728) at
parser/hf.c:116
#6 0x2b95e687e8de in clean_msg_clone (msg=0x2b95e9de7758,
min=0x2b95e9de7758, max=0x2b95e9de8d70) at sip_msg.h:54
#7 0x2b95e687e7b7 in run_trans_callbacks (type=2,
trans=0x2b95e9fe5150, req=0x2b95e9de7758, rpl=0x7c0eb8, code=200) at
t_hooks.c:245
#8 0x2b95e688539d in t_reply_matching (p_msg=0x7c0eb8,
p_branch=0x7fff77e144b8) at t_lookup.c:888
#9 0x2b95e6885997 in t_check (p_msg=0x7c0eb8,
param_branch=0x7fff77e144b8) at t_lookup.c:964
#10 0x2b95e689479b in reply_received (p_msg=0x7c0eb8) at
t_reply.c:1395
#11 0x0041c6db in forward_reply (msg=0x7c0eb8) at forward.c:576
#12 0x0043ccf0 in receive_msg (
buf=0x712980 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
XXX.XX.XXX.13;branch=z9hG4bK2cb3.224aa3e4.0;received=XXX.XX.XXX.13\r\nVia:
SIP/2.0/UDP
XXX.XX.XXX.236:5060;received=XXX.XX.XXX.236;branch=z9hG4bK3ca41325;rport=5060\r\nRec"...,
len=576, rcv_info=0x7fff77e14610) at receive.c:212
#13 0x004692e3 in udp_rcv_loop () at udp_server.c:449
#14 0x00420ecb in main_loop () at main.c:774
#15 0x00422e0f in main (argc=11, argv=0x7fff77e14898) at
main.c:1321
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/openser/openser.pid -m 32 -u openser -g op'.
Program terminated with signal 11, Segmentation fault.
#0 0x0046bf7b in add_avp_galias_str
(alias_definition=0x46de56 "") at usr_avp.c:680
680LM_ERR("parse error in <%s> around pos %ld\n",
(gdb) backtrace
#0 0x0046bf7b in add_avp_galias_str
(alias_definition=0x46de56 "") at usr_avp.c:680
#1 0x in ?? ()
On 02/10/2011 09:14 AM, Daniel-Constantin Mierla wrote:
On 2/10/11 8:12 AM, Andrew O. Zhukov wrote:
Couple month ago I
Re: [SR-Users] Error running kamailio 3.1.0
Hello, looks like you installed 3.1 over 3.0. sl module is now in modules/ folder. In 3.0 was in modules_k folder, so it finds the old version first. Delete the content of /usr/local/lib/kamailio/ and then install again. Cheers, Daniel On 2/11/11 6:09 PM, Lucas Alvarez wrote: Hi, I have compiled kamailio 3.1.0 without any error and I having this error when running kamailio: ERROR: [sr_module.c:523]: ERROR: load_module: could not open module : /usr/local/lib/kamailio/modules_k/sl.so: undefined symbol: fm_malloc Any will be appreciated. Regards, Lucas ___ 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
