Re: [SR-Users] How to delay messages when msilo messages are dumped

[Daniel-Constantin Mierla]

Hello,

you could try to send the messages back to kamailio via outbound proxy
option, then add some delay via script operations. Be careful not to
block the sip worker processes, therefore look at the asynchronous
routing options.

Of course, patching the module and writing a bit of c code can be also a
solution.

Another one is to make some external script that fetches from the
database and injects sip messages (e.g., via sipsak or sipp) at the pace
you want.

Cheers,
Daniel


On 07.07.17 17:02, Rahul Mehta wrote:
> Hello,
>
> We are facing scenario when msilo dump function is called the user's
> device gets hanged/crash as messages are sent together to the user 
> who gets online,please provide solution how to delay the messages
> which are send to the user when 'm_dump' function is called.
>
> I am providing the code of m_dump function
>
>
>  if (m_dump("$fu"))
>  {
> xlog("L_INFO","MSILO: offline messages
> dumped - if they were\n");
>   }else{
> xlog("L_INFO","MSILO: no offline
> messages dumped\n");
>  };
>
>
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] TR: Failure Mode

[Daniel-Constantin Mierla]

Hello,

looking at the trace, the routing is parallel forking, because the two
branches are sent out at the same time, it is no final response to the
first branch before the second is sent out.

Are you sure you sent out the second branch from failure route? From the
sip trace is doesn't seem so.

Cheers,
Daniel


On 07.07.17 15:38, Nicolas Breuer wrote:
>
> Hello Daniel,
>
>  
>
> Thanks !
>
>  
>
> I sent all the information’s to your email address
>
>  
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* vendredi 7 juillet 2017 13:21
> *À :* Nicolas Breuer ; Kamailio (SER) -
> Users Mailing List 
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Can you get a ngrep trace captured on kamailio server for such situation?
>
> Also, can you paste the failure_route block here along with the log
> messages from the syslog?
>
> Cheers,
> Daniel
>
>  
>
> On 07.07.17 12:42, Nicolas Breuer wrote:
>
> I think serial because the new branch is only created in case the
> first is timeout.
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* vendredi 7 juillet 2017 12:40
> *À :* Kamailio (SER) - Users Mailing List
> 
> ; Nicolas Breuer
>  
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Hello,
>
> are you doing parallel forking or serial forking?
>
> Cheers,
> Daniel
>
>  
>
> On 07.07.17 12:24, Nicolas Breuer wrote:
>
> * *
>
>  
>
> Hello,
>
>  
>
> Some help here is needed
>
>  
>
> # auto-discard branches from previous serial forking leg
>
> modparam("tm", "failure_reply_mode", 3)
>
>  
>
> I test a call with two branches.
>
>  
>
> 1^st branch received a 408 timeout error
>
> 2nd branch received a 486 busy.
>
>  
>
> Normally the failure route should be with the 486.
>
>  
>
> NOTICE: 

[SR-Users] m_dump sends multiple messages

[Rahul Mehta]

hello,
   when m_dump() function is called as user gets online, the function
i.e=m_dump() sends multiple copies of same message,can anyone please
provide way to stop m_dump() sending multiple copies of same message.

I am providing the code of m_dump function


 if (m_dump("$fu"))
 {
xlog("L_INFO","MSILO: offline messages
dumped - if they were\n");
  }else{
xlog("L_INFO","MSILO: no offline messages
dumped\n");
 };
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] domain vs uid_domain module

[Daniel-Constantin Mierla]

Hello,

in short, if you were not using uid_domain module so far, I would
recommend to use the domain module.

The uid_domain module comes from SER branch of the project, while the
domain module comes from Kamailio branch (during 2005-2008, they were
separate projects). Afaik, uid_domain didn't get much attention lately,
it doesn't mean that is not working, but most of the work was with
domain module. They used to have different database structure and
different internal processing.

Same for the other uid_* modules, their origin is in SER branch, but
there should be alternatives offered by Kamailio branch. They are kept
for the people that used to run the SER branch, but I am not sure if
they are many left these days...

Cheers,
Daniel


On 07.07.17 14:41, Huber Andreas wrote:
>
> Hi,
>
>  
>
> I was comparing the documentation of the “uid_domain” and “domain”
> modules and I was wondering what is the main difference between the
> two modules.
>
> While the “uid_domain” module has more documentation, it seems to me
> that both modules are offering very similar functionality, or am I
> missing something ?
>
>  
>
> Also I found it curious that the documentation of the “uid_domain”
> module uses “domain” as the module name in all its examples for the
> module configuration. E.g.
>
> modparam("domain", "domain_table", "new_name")
>
>  
>
> But when I try to use the “uid_domain” module, I actually have to
> specify the parameters as :
>
> modparam("uid_domain", "domain_table", "new_name")
>
>  
>
>  
>
> The same question also applies to the “uid_auth_db” module that
> resembles closely the “auth_db” module in the documentation, but not
> in the implementation.
>
>  
>
> Kind Regards,
>
> Andreas
>
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamctl v5 issues sending rpc from jsonrpc_exec_ex

[Daniel-Constantin Mierla]

OK, good that it was sorted out.

Cheers,
Daniel


On 10.07.17 09:14, Abdoul Osséni wrote:
> Hello,
>
> Thank you for your email.
>
> I found where the problem was: my jsonrpc command was not valid.
>
> Regards
> Abdoul.
>  
>
>
> 2017-07-10 9:05 GMT+02:00 Daniel-Constantin Mierla  >:
>
> Hello,
>
> how do you execute the jsonrpc command? Do you use one of the
> tools provided by kamailio?
>
> Is the dialog module loaded?
>
> What is the exact version of kamailio (output of kamailio -v)?
>
> Cheers,
> Daniel
>
> On 07.07.17 16:36, Abdoul Osséni wrote:
>> Hello,
>>
>> Got this error :
>>
>> ERROR: jsonrpcs [jsonrpcs_mod.c:1323]: jsonrpc_exec_ex(): method
>> callback not found [dlg.end_dlg 3660 9594]
>>
>> Regards
>>
>>
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org 
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> 
>
> -- 
> Daniel-Constantin Mierla
> www.twitter.com/miconda  -- 
> www.linkedin.com/in/miconda 
> Kamailio Advanced Training - www.asipto.com 
> Kamailio World Conference - www.kamailioworld.com 
> 
>
>
>
>
>

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Database connection handles vs. processes

[Alex Balashov]

Hi,

By way of illustration, I have one server with children=8, a single UDP
listener, and 23 processes total:

--
21117   attendant
21118   udp receiver child=0 sock=xxx.xxx.xxx.xxx:5060
21119   udp receiver child=1 sock=xxx.xxx.xxx.xxx:5060
21120   udp receiver child=2 sock=xxx.xxx.xxx.xxx:5060
21121   udp receiver child=3 sock=xxx.xxx.xxx.xxx:5060
21122   udp receiver child=4 sock=xxx.xxx.xxx.xxx:5060
21123   udp receiver child=5 sock=xxx.xxx.xxx.xxx:5060
21124   udp receiver child=6 sock=xxx.xxx.xxx.xxx:5060
21125   udp receiver child=7 sock=xxx.xxx.xxx.xxx:5060
21126   slow timer
21127   timer
21128   MI FIFO
21129   ctl handler
21130   RTIMER USEC EXEC
21131   RTIMER USEC EXEC
21132   RTIMER USEC EXEC
21133   RTIMER USEC EXEC
21134   RTIMER USEC EXEC
21135   RTIMER USEC EXEC
21136   RTIMER USEC EXEC
21137   Dialog KA Timer
21138   Dialog Clean Timer
21139   tcp main process

# kamcmd -s /tmp/kamailio_ctl ps | wc -l
23
--

This appears to result in 23 total database connections to the Postgres
server:

--
# lsof -n | grep -i '^kam' | grep IPv4 | grep TCP | grep -i :postgres | wc -l
23
--

But I have another Kamailio server that has three listeners, two UDP and
one TCP, and children=24, i.e.

--
children=24
listen=udp:xxx.xxx.xxx.xxx:5060
listen=udp:yyy.yyy.yyy.yyy:5060
listen=tcp:zzz.zzz.zzz.zzz:5060
--

I am given to understand that the total number of worker processes there
will be (children_setting * listeners), i.e. 72 in this case, plus some
number of rtimer and supervisory processes, as in my case. And true
enough:

--
# kamcmd -s /tmp/kamailio_ctl ps | wc -l
86
# kamcmd -s /tmp/kamailio_ctl ps | sed 's/65.254.44.195/yyy.yyy.yyy.yyy/g' | 
sed 's/65.254.44.194/zzz.zzz.zzz.zzz/g'
22065   main process - attendant
22069   udp receiver child=0 sock=zzz.zzz.zzz.zzz:5060
22070   udp receiver child=1 sock=zzz.zzz.zzz.zzz:5060
22071   udp receiver child=2 sock=zzz.zzz.zzz.zzz:5060
22073   udp receiver child=3 sock=zzz.zzz.zzz.zzz:5060
22074   udp receiver child=4 sock=zzz.zzz.zzz.zzz:5060
22076   udp receiver child=5 sock=zzz.zzz.zzz.zzz:5060
22079   udp receiver child=6 sock=zzz.zzz.zzz.zzz:5060
22080   udp receiver child=7 sock=zzz.zzz.zzz.zzz:5060
22082   udp receiver child=8 sock=zzz.zzz.zzz.zzz:5060
22085   udp receiver child=9 sock=zzz.zzz.zzz.zzz:5060
22086   udp receiver child=10 sock=zzz.zzz.zzz.zzz:5060
22089   udp receiver child=11 sock=zzz.zzz.zzz.zzz:5060
22091   udp receiver child=12 sock=zzz.zzz.zzz.zzz:5060
22093   udp receiver child=13 sock=zzz.zzz.zzz.zzz:5060
22095   udp receiver child=14 sock=zzz.zzz.zzz.zzz:5060
22097   udp receiver child=15 sock=zzz.zzz.zzz.zzz:5060
22099   udp receiver child=16 sock=zzz.zzz.zzz.zzz:5060
22100   udp receiver child=17 sock=zzz.zzz.zzz.zzz:5060
22103   udp receiver child=18 sock=zzz.zzz.zzz.zzz:5060
22105   udp receiver child=19 sock=zzz.zzz.zzz.zzz:5060
22107   udp receiver child=20 sock=zzz.zzz.zzz.zzz:5060
22109   udp receiver child=21 sock=zzz.zzz.zzz.zzz:5060
22111   udp receiver child=22 sock=zzz.zzz.zzz.zzz:5060
22113   udp receiver child=23 sock=zzz.zzz.zzz.zzz:5060
22115   udp receiver child=0 sock=yyy.yyy.yyy.yyy:5060
22117   udp receiver child=1 sock=yyy.yyy.yyy.yyy:5060
22119   udp receiver child=2 sock=yyy.yyy.yyy.yyy:5060
22121   udp receiver child=3 sock=yyy.yyy.yyy.yyy:5060
22123   udp receiver child=4 sock=yyy.yyy.yyy.yyy:5060
22125   udp receiver child=5 sock=yyy.yyy.yyy.yyy:5060
22127   udp receiver child=6 sock=yyy.yyy.yyy.yyy:5060
22129   udp receiver child=7 sock=yyy.yyy.yyy.yyy:5060
22131   udp receiver child=8 sock=yyy.yyy.yyy.yyy:5060
22132   udp receiver child=9 sock=yyy.yyy.yyy.yyy:5060
22135   udp receiver child=10 sock=yyy.yyy.yyy.yyy:5060
22137   udp receiver child=11 sock=yyy.yyy.yyy.yyy:5060
22139   udp receiver child=12 sock=yyy.yyy.yyy.yyy:5060
22141   udp receiver child=13 sock=yyy.yyy.yyy.yyy:5060
22143   udp receiver child=14 sock=yyy.yyy.yyy.yyy:5060
22145   udp receiver child=15 sock=yyy.yyy.yyy.yyy:5060
22147   udp receiver child=16 sock=yyy.yyy.yyy.yyy:5060
22149   udp receiver child=17 sock=yyy.yyy.yyy.yyy:5060
22151   udp receiver child=18 sock=yyy.yyy.yyy.yyy:5060
22153   udp receiver child=19 sock=yyy.yyy.yyy.yyy:5060
22155   udp receiver child=20 sock=yyy.yyy.yyy.yyy:5060
22156   udp receiver child=21 sock=yyy.yyy.yyy.yyy:5060
22159   udp receiver child=22 sock=yyy.yyy.yyy.yyy:5060
22161   udp receiver child=23 sock=yyy.yyy.yyy.yyy:5060
22163   slow timer
22165   timer
22167   secondary timer
22168   ctl handler
22169   RTIMER USEC EXEC
22170   RTIMER USEC EXEC
22172   RTIMER USEC EXEC
22173   RTIMER USEC EXEC
22175   Dialog Clean Timer
22176   TIMER NH
22177   TIMER NH
22178   TIMER NH
22179   tcp receiver (generic) child=0
22180   tcp receiver (generic) child=1
22182   tcp receiver (generic) child=2
22184   tcp receiver (generic) child=3
22186   tcp receiver (generic) child=4
22188   tcp receiver (generic) child=5
22190   tcp receiver (generic) child=6
22192   tcp receiver (generic) child=7
22194   tcp 

Re: [SR-Users] Database connection handles vs. processes

[E. Schmidbauer]

some modules can have child processes that each maintain a database
connection. the number of child processes for a module can sometimes be set
using a modparam() for that module

On Mon, Jul 10, 2017 at 4:23 PM, Alex Balashov 
wrote:

> Hi,
>
> By way of illustration, I have one server with children=8, a single UDP
> listener, and 23 processes total:
>
> --
> 21117   attendant
> 21118   udp receiver child=0 sock=xxx.xxx.xxx.xxx:5060
> 21119   udp receiver child=1 sock=xxx.xxx.xxx.xxx:5060
> 21120   udp receiver child=2 sock=xxx.xxx.xxx.xxx:5060
> 21121   udp receiver child=3 sock=xxx.xxx.xxx.xxx:5060
> 21122   udp receiver child=4 sock=xxx.xxx.xxx.xxx:5060
> 21123   udp receiver child=5 sock=xxx.xxx.xxx.xxx:5060
> 21124   udp receiver child=6 sock=xxx.xxx.xxx.xxx:5060
> 21125   udp receiver child=7 sock=xxx.xxx.xxx.xxx:5060
> 21126   slow timer
> 21127   timer
> 21128   MI FIFO
> 21129   ctl handler
> 21130   RTIMER USEC EXEC
> 21131   RTIMER USEC EXEC
> 21132   RTIMER USEC EXEC
> 21133   RTIMER USEC EXEC
> 21134   RTIMER USEC EXEC
> 21135   RTIMER USEC EXEC
> 21136   RTIMER USEC EXEC
> 21137   Dialog KA Timer
> 21138   Dialog Clean Timer
> 21139   tcp main process
>
> # kamcmd -s /tmp/kamailio_ctl ps | wc -l
> 23
> --
>
> This appears to result in 23 total database connections to the Postgres
> server:
>
> --
> # lsof -n | grep -i '^kam' | grep IPv4 | grep TCP | grep -i :postgres | wc
> -l
> 23
> --
>
> But I have another Kamailio server that has three listeners, two UDP and
> one TCP, and children=24, i.e.
>
> --
> children=24
> listen=udp:xxx.xxx.xxx.xxx:5060
> listen=udp:yyy.yyy.yyy.yyy:5060
> listen=tcp:zzz.zzz.zzz.zzz:5060
> --
>
> I am given to understand that the total number of worker processes there
> will be (children_setting * listeners), i.e. 72 in this case, plus some
> number of rtimer and supervisory processes, as in my case. And true
> enough:
>
> --
> # kamcmd -s /tmp/kamailio_ctl ps | wc -l
> 86
> # kamcmd -s /tmp/kamailio_ctl ps | sed 's/65.254.44.195/yyy.yyy.yyy.yyy/g'
> | sed 's/65.254.44.194/zzz.zzz.zzz.zzz/g'
> 22065   main process - attendant
> 22069   udp receiver child=0 sock=zzz.zzz.zzz.zzz:5060
> 22070   udp receiver child=1 sock=zzz.zzz.zzz.zzz:5060
> 22071   udp receiver child=2 sock=zzz.zzz.zzz.zzz:5060
> 22073   udp receiver child=3 sock=zzz.zzz.zzz.zzz:5060
> 22074   udp receiver child=4 sock=zzz.zzz.zzz.zzz:5060
> 22076   udp receiver child=5 sock=zzz.zzz.zzz.zzz:5060
> 22079   udp receiver child=6 sock=zzz.zzz.zzz.zzz:5060
> 22080   udp receiver child=7 sock=zzz.zzz.zzz.zzz:5060
> 22082   udp receiver child=8 sock=zzz.zzz.zzz.zzz:5060
> 22085   udp receiver child=9 sock=zzz.zzz.zzz.zzz:5060
> 22086   udp receiver child=10 sock=zzz.zzz.zzz.zzz:5060
> 22089   udp receiver child=11 sock=zzz.zzz.zzz.zzz:5060
> 22091   udp receiver child=12 sock=zzz.zzz.zzz.zzz:5060
> 22093   udp receiver child=13 sock=zzz.zzz.zzz.zzz:5060
> 22095   udp receiver child=14 sock=zzz.zzz.zzz.zzz:5060
> 22097   udp receiver child=15 sock=zzz.zzz.zzz.zzz:5060
> 22099   udp receiver child=16 sock=zzz.zzz.zzz.zzz:5060
> 22100   udp receiver child=17 sock=zzz.zzz.zzz.zzz:5060
> 22103   udp receiver child=18 sock=zzz.zzz.zzz.zzz:5060
> 22105   udp receiver child=19 sock=zzz.zzz.zzz.zzz:5060
> 22107   udp receiver child=20 sock=zzz.zzz.zzz.zzz:5060
> 22109   udp receiver child=21 sock=zzz.zzz.zzz.zzz:5060
> 22111   udp receiver child=22 sock=zzz.zzz.zzz.zzz:5060
> 22113   udp receiver child=23 sock=zzz.zzz.zzz.zzz:5060
> 22115   udp receiver child=0 sock=yyy.yyy.yyy.yyy:5060
> 22117   udp receiver child=1 sock=yyy.yyy.yyy.yyy:5060
> 22119   udp receiver child=2 sock=yyy.yyy.yyy.yyy:5060
> 22121   udp receiver child=3 sock=yyy.yyy.yyy.yyy:5060
> 22123   udp receiver child=4 sock=yyy.yyy.yyy.yyy:5060
> 22125   udp receiver child=5 sock=yyy.yyy.yyy.yyy:5060
> 22127   udp receiver child=6 sock=yyy.yyy.yyy.yyy:5060
> 22129   udp receiver child=7 sock=yyy.yyy.yyy.yyy:5060
> 22131   udp receiver child=8 sock=yyy.yyy.yyy.yyy:5060
> 22132   udp receiver child=9 sock=yyy.yyy.yyy.yyy:5060
> 22135   udp receiver child=10 sock=yyy.yyy.yyy.yyy:5060
> 22137   udp receiver child=11 sock=yyy.yyy.yyy.yyy:5060
> 22139   udp receiver child=12 sock=yyy.yyy.yyy.yyy:5060
> 22141   udp receiver child=13 sock=yyy.yyy.yyy.yyy:5060
> 22143   udp receiver child=14 sock=yyy.yyy.yyy.yyy:5060
> 22145   udp receiver child=15 sock=yyy.yyy.yyy.yyy:5060
> 22147   udp receiver child=16 sock=yyy.yyy.yyy.yyy:5060
> 22149   udp receiver child=17 sock=yyy.yyy.yyy.yyy:5060
> 22151   udp receiver child=18 sock=yyy.yyy.yyy.yyy:5060
> 22153   udp receiver child=19 sock=yyy.yyy.yyy.yyy:5060
> 22155   udp receiver child=20 sock=yyy.yyy.yyy.yyy:5060
> 22156   udp receiver child=21 sock=yyy.yyy.yyy.yyy:5060
> 22159   udp receiver child=22 sock=yyy.yyy.yyy.yyy:5060
> 22161   udp receiver child=23 sock=yyy.yyy.yyy.yyy:5060
> 22163   slow timer
> 22165   timer
> 22167   secondary timer
> 22168   ctl handler
> 22169   RTIMER 

Re: [SR-Users] Database connection handles vs. processes

[Alex Balashov]

On Mon, Jul 10, 2017 at 05:04:32PM -0400, E. Schmidbauer wrote:

> some modules can have child processes that each maintain a database
> connection. the number of child processes for a module can sometimes be set
> using a modparam() for that module

Well, indeed, and that is germane.

However, it doesn't explain the disproportionate number of DB
connections relative to absolute number of child processes running, in
total, and why some processes appear to generate multiple connections.

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] deb nightly-builds not being built

[Victor Seva]

On 07/03/2017 11:53 PM, Victor Seva wrote:
> We are having some issues with our building infrastructure so packages
> are not being built. We are working on it, please be patient.

Build process working again.

For the curious changes performed are in [0], they were related to
jenkins needing Java 1.8 [1]

[0] https://github.com/sipwise/kamailio-deb-jenkins
[1] https://issues.jenkins-ci.org/browse/JENKINS-43492

Cheers,
Victor Seva



signature.asc
Description: OpenPGP digital signature
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] deb nightly-builds not being built

[Daniel-Constantin Mierla]

On 10.07.17 12:43, Victor Seva wrote:
> On 07/03/2017 11:53 PM, Victor Seva wrote:
>> We are having some issues with our building infrastructure so packages
>> are not being built. We are working on it, please be patient.
> Build process working again.
>
> For the curious changes performed are in [0], they were related to
> jenkins needing Java 1.8 [1]
>
> [0] https://github.com/sipwise/kamailio-deb-jenkins
> [1] https://issues.jenkins-ci.org/browse/JENKINS-43492
Thanks for update, time and resources spent on this!

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] TR: Failure Mode

[Daniel-Constantin Mierla]

Hello,

the new trace shows a serial forking, with the first branch timing out,
but the second branch is getting a 183 response, and that's all. It is
not the same scenario you described. I need the full trace, from initial
invite to the final response sent back to caller to see what is the
winning response code.

Cheers,
Daniel


On 10.07.17 10:10, Nicolas Breuer wrote:
>
> Hello,
>
>  
>
> Yes I’m sure the second branch is launched from Branch Failure Route.
>
> If you check the timer trace, you can see the second is send 4 seconds
> later than the first ( I set the tm_inv to 4 seconds )
>
>  
>
> But in the trace I sent you the “last” invite. The kamailio sent 4
> invites.
>
>  
>
> I will send you the complete trace
>
>  
>
>  
>
>  
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* lundi 10 juillet 2017 09:20
> *À :* Nicolas Breuer ; Kamailio (SER) -
> Users Mailing List 
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Hello,
>
> looking at the trace, the routing is parallel forking, because the two
> branches are sent out at the same time, it is no final response to the
> first branch before the second is sent out.
>
> Are you sure you sent out the second branch from failure route? From
> the sip trace is doesn't seem so.
>
> Cheers,
> Daniel
>
>  
>
> On 07.07.17 15:38, Nicolas Breuer wrote:
>
> Hello Daniel,
>
>  
>
> Thanks !
>
>  
>
> I sent all the information’s to your email address
>
>  
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* vendredi 7 juillet 2017 13:21
> *À :* Nicolas Breuer 
> ; Kamailio (SER) - Users
> Mailing List 
> 
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Can you get a ngrep trace captured on kamailio server for such
> situation?
>
> Also, can you paste the failure_route block here along with the
> log messages from the syslog?
>
> Cheers,
> Daniel
>
>  
>
> On 07.07.17 12:42, Nicolas Breuer wrote:
>
> I think serial because the new branch is only created in case
> the first is timeout.
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* vendredi 7 juillet 2017 12:40
> *À :* Kamailio (SER) - Users Mailing List
> 
> ; Nicolas Breuer
> 
> 
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Hello,
>
> are you doing parallel forking or serial forking?
>
> Cheers,
> Daniel
>
>  
>
> On 07.07.17 12:24, Nicolas Breuer wrote:
>
> * *
>
>  
>
> Hello,
>
>  
>
> Some help here is needed
>
>  
>
> # auto-discard branches from previous serial forking leg
>
> modparam("tm", "failure_reply_mode", 3)
>
>  
>
> I test a call with two branches.
>
>  
>
> 1^st branch received a 408 timeout error
>
> 2nd branch received a 486 busy.
>
>  
>
> Normally the failure route should be with the 486.
>
>  
>
> NOTICE: 

Re: [SR-Users] Random Proxy Crash, Restarted OK Anything Here For Concern?

[Daniel-Constantin Mierla]

Hello,

I would suggest to update to latest 4.1.x version, the 4.1.0 is the
first in the 4.1 series and many issues have been fixed in later 4.1.x
version. There should be no database structure update or config changes,
just deploy a newer 4.1.x version and restart.

The double free crashes can be avoided with config parameter
mem_safety=1, but it can be side effect of another bug that may hit
anyhow at some point, however, you may also get around it in a nicer way.

Cheers,
Daniel

On 07.07.17 18:34, JR Richardson wrote:
> Hi All,
>
> I have a basic proxy up and running for over 6 months without issue,
> had a random crash, not sure why. Restarted kamailio process and it's
> working as expected. Any clue is the log to indicate what might have
> happened?
>
> snip
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13416]: :
>  [mem/q_malloc.c:468]: qm_free(): BUG: qm_free: freeing already
> freed pointer (0x7fa1e1ebd658), called from : mem/shm_mem.c:
> sh_realloc(88), first free : mem/shm_mem.c: sh_realloc(88) -
> aborting
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13415]:
> ALERT:  [main.c:775]: handle_sigs(): child process 13416 exited
> by a signal 6
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13415]:
> ALERT:  [main.c:778]: handle_sigs(): core was not generated
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13415]:
> INFO:  [main.c:790]: handle_sigs(): INFO: terminating due to
> SIGCHLD
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13423]:
> INFO:  [main.c:841]: sig_usr(): INFO: signal 15 received
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13420]:
> INFO:  [main.c:841]: sig_usr(): INFO: signal 15 received
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13424]:
> INFO:  [main.c:841]: sig_usr(): INFO: signal 15 received
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13419]:
> INFO:  [main.c:841]: sig_usr(): INFO: signal 15 received
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13421]:
> INFO:  [main.c:841]: sig_usr(): INFO: signal 15 received
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13422]:
> INFO:  [main.c:841]: sig_usr(): INFO: signal 15 received
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13418]:
> INFO:  [main.c:841]: sig_usr(): INFO: signal 15 received
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13417]:
> INFO:  [main.c:841]: sig_usr(): INFO: signal 15 received
> Jul  5 16:31:46 sip-router3-ve206 /usr/local/sbin/kamailio[13415]:
> ERROR: ctl [ctl.c:379]: mod_destroy(): ERROR: ctl: could not delete
> unix socket /tmp/kamailio_ctl: Operation not permitted (1)
> snip
>
> RTPProxy also running on the server was not affected.
>
> root@sip-router3-ve206:/var/log# kamailio -V
> version: kamailio 4.1.0 (x86_64/linux) 350d2e
> flags: STATS: Off, 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, DEFAULT PKG_SIZE 4MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: 350d2e
> compiled on 16:41:38 Dec 17 2013 with gcc 4.4.5
>
> Yes, I know it's an older version but I prefer not to upgrade unless
> absolutely necessary. I'm sure this was a random event, not too
> concerned but since it is a production server, I'm obligated to
> investigate.
>
> Thanks.
>
> JR

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] app_lua reload - what exactly gets reloaded?

[Daniel-Constantin Mierla]

Hello,


On 07.07.17 15:02, Sebastian Damm wrote:
> Hi,
>
> On Thu, Jul 6, 2017 at 12:26 PM, Daniel-Constantin Mierla
>  wrote:
>> You can check a shared memory variable (like $sht(...) or $shv(...))
>> that you can change via rpc, so you can re-fetch the database records
>> even if you don't change the lua script.
> I've implemented it as suggested, and it works as expected.
>
> Thanks as always for the valuable input.
>
ok, great!

Maybe someone is going to implement the interpreter reset feature, could
be useful as well, although so far I didn't need it at all.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamctl v5 issues sending rpc from jsonrpc_exec_ex

[Daniel-Constantin Mierla]

Hello,

how do you execute the jsonrpc command? Do you use one of the tools
provided by kamailio?

Is the dialog module loaded?

What is the exact version of kamailio (output of kamailio -v)?

Cheers,
Daniel

On 07.07.17 16:36, Abdoul Osséni wrote:
> Hello,
>
> Got this error :
>
> ERROR: jsonrpcs [jsonrpcs_mod.c:1323]: jsonrpc_exec_ex(): method
> callback not found [dlg.end_dlg 3660 9594]
>
> Regards
>
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamctl v5 issues sending rpc from jsonrpc_exec_ex

[Abdoul Osséni]

Hello,

Thank you for your email.

I found where the problem was: my jsonrpc command was not valid.

Regards
Abdoul.



2017-07-10 9:05 GMT+02:00 Daniel-Constantin Mierla :

> Hello,
>
> how do you execute the jsonrpc command? Do you use one of the tools
> provided by kamailio?
>
> Is the dialog module loaded?
> What is the exact version of kamailio (output of kamailio -v)?
>
> Cheers,
> Daniel
>
> On 07.07.17 16:36, Abdoul Osséni wrote:
>
> Hello,
>
> Got this error :
>
> ERROR: jsonrpcs [jsonrpcs_mod.c:1323]: jsonrpc_exec_ex(): method callback
> not found [dlg.end_dlg 3660 9594]
>
> Regards
>
>
>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - www.asipto.com
> Kamailio World Conference - www.kamailioworld.com
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users