Re: [SR-Users] memory issue with jsonrpc

2019-02-11 Thread Benjamin Roy
Yes, that option looks promising and I just enabled it. I'll watch it for
the next few days to see if that solve the problem.

Thanks!
-Ben



On Mon, Feb 11, 2019 at 2:38 PM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> can you try with the next global parameter?
>
> mem_join = yes
>
> Cheers,
> Daniel
> On 11.02.19 22:57, Benjamin Roy wrote:
>
> Hi, I'm hoping someone can guide me in the right direction.
>
> In kamailio 5.2.1 I'm getting the following memory errors after a while
> (hours or days) of sending messages with jsonrpc. Restarting kamailio
> clears them for a while. Any suggestions on what I should change, or how to
> better identify the issue?
>
> 24(6177) ERROR:  [core/mem/q_malloc.c:291]: qm_find_free():
> qm_find_free(0x7f1cbe6fd000, 5712); Free fragment not found!
> 24(6177) ERROR:  [core/mem/q_malloc.c:425]: qm_malloc():
> qm_malloc(0x7f1cbe6fd000, 5712) called from tm: h_table.c: build_cell(339),
> module: tm; Free fragment not found!
> 24(6177) ERROR: tm [uac.c:422]: t_uac_prepare(): short of cell shmem
> 24(6177) ERROR: pua [send_publish.c:700]: send_publish(): in t_request tm
> module function
> 24(6177) ERROR: pua_rpc [pua_rpc.c:280]: pua_rpc_publish_mode(): pua
> send_publish failed
>
> I have these buffer values in the config file
> tcp_rd_buf_size=65536
> pv_buffer_size=32768
>
> and I'm running kamailio with these memory options "-m 1024 -M 16"
>
> The jsonrpc message I'm sending look like this
> {
> "jsonrpc": "2.0",
> "method": "pua.publish",
> "params": [
> "sip:172.1.1.3:5060;transport=tcp",
> "300",
> "reg",
> "application/reginfo+xml",
> ".",
> ".",
> ".",
> ".",
> "
>  xmlns='urn:ietf:params:xml:ns:reginfo' xmlns:xsi='
> http://www.w3.org/2001/XMLSchema-instance'>
> 
>  id='c19685--1732979172--1829864152-2' q='1.0' state='active'>
> sips:5@172.1.2.4:62270;transport=tls;avaya-sc-enabled
> 
> 
> 
> 
> 
> "
> ],
> "id": 1
> }
>
> Thanks,
> -Ben
>
>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in 
> Washington, DC, USA -- www.asipto.com
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] memory issue with jsonrpc

2019-02-11 Thread Daniel-Constantin Mierla
Hello,

can you try with the next global parameter?

mem_join = yes

Cheers,
Daniel

On 11.02.19 22:57, Benjamin Roy wrote:
> Hi, I'm hoping someone can guide me in the right direction.
>
> In kamailio 5.2.1 I'm getting the following memory errors after a
> while (hours or days) of sending messages with jsonrpc. Restarting
> kamailio clears them for a while. Any suggestions on what I should
> change, or how to better identify the issue?
>
> 24(6177) ERROR:  [core/mem/q_malloc.c:291]: qm_find_free():
> qm_find_free(0x7f1cbe6fd000, 5712); Free fragment not found!
> 24(6177) ERROR:  [core/mem/q_malloc.c:425]: qm_malloc():
> qm_malloc(0x7f1cbe6fd000, 5712) called from tm: h_table.c:
> build_cell(339), module: tm; Free fragment not found!
> 24(6177) ERROR: tm [uac.c:422]: t_uac_prepare(): short of cell shmem
> 24(6177) ERROR: pua [send_publish.c:700]: send_publish(): in t_request
> tm module function
> 24(6177) ERROR: pua_rpc [pua_rpc.c:280]: pua_rpc_publish_mode(): pua
> send_publish failed
>
> I have these buffer values in the config file
> tcp_rd_buf_size=65536
> pv_buffer_size=32768
>
> and I'm running kamailio with these memory options "-m 1024 -M 16"
>
> The jsonrpc message I'm sending look like this
> {
> "jsonrpc": "2.0", 
> "method": "pua.publish", 
> "params": [
> "sip:172.1.1.3:5060;transport=tcp", 
> "300", 
> "reg", 
> "application/reginfo+xml", 
> ".", 
> ".", 
> ".", 
> ".",
> "
>  xmlns='urn:ietf:params:xml:ns:reginfo'
> xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
>      id='a19685' state='active'>
>      id='c19685--1732979172--1829864152-2' q='1.0' state='active'>
>        
> sips:5@172.1.2.4:62270;transport=tls;avaya-sc-enabled
>         
>     
>     
> 
> "
> ], 
> "id": 1
> }
>
> Thanks,
> -Ben
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in 
Washington, DC, USA -- www.asipto.com

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


[SR-Users] memory issue with jsonrpc

2019-02-11 Thread Benjamin Roy
Hi, I'm hoping someone can guide me in the right direction.

In kamailio 5.2.1 I'm getting the following memory errors after a while
(hours or days) of sending messages with jsonrpc. Restarting kamailio
clears them for a while. Any suggestions on what I should change, or how to
better identify the issue?

24(6177) ERROR:  [core/mem/q_malloc.c:291]: qm_find_free():
qm_find_free(0x7f1cbe6fd000, 5712); Free fragment not found!
24(6177) ERROR:  [core/mem/q_malloc.c:425]: qm_malloc():
qm_malloc(0x7f1cbe6fd000, 5712) called from tm: h_table.c: build_cell(339),
module: tm; Free fragment not found!
24(6177) ERROR: tm [uac.c:422]: t_uac_prepare(): short of cell shmem
24(6177) ERROR: pua [send_publish.c:700]: send_publish(): in t_request tm
module function
24(6177) ERROR: pua_rpc [pua_rpc.c:280]: pua_rpc_publish_mode(): pua
send_publish failed

I have these buffer values in the config file
tcp_rd_buf_size=65536
pv_buffer_size=32768

and I'm running kamailio with these memory options "-m 1024 -M 16"

The jsonrpc message I'm sending look like this
{
"jsonrpc": "2.0",
"method": "pua.publish",
"params": [
"sip:172.1.1.3:5060;transport=tcp",
"300",
"reg",
"application/reginfo+xml",
".",
".",
".",
".",
"



sips:5@172.1.2.4:62270;transport=tls;avaya-sc-enabled




"
],
"id": 1
}

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


Re: [SR-Users] Repository for automatic deployment of Kamailio

2019-02-11 Thread Henning Westerholt
Am Montag, 11. Februar 2019, 18:55:02 CET schrieb Gholamreza Sabery:
> A few years ago, I developed an Ansible repository for automatic deployment
> of Kamailio. Recently, I added some new features, and now you can deploy
> the playbooks on Docker containers. I think it is a good starting point for
> anyone who wants to deploy and use Kamailio for the first time. Link of the
> repository:
> 
> https://github.com/ghrst/Kamailio-HA

Hello Gholamreza,

sounds great, thank you for sharing. If you like you can add it it as a link 
to our wiki (https://www.kamailio.org/wiki/) maybe in the "Installation On 
containers" section.

If you want to maintain and extend it in the future, we could even think off 
to add this as sub-repository to github kamailio. Maybe some of the other 
developers can share their opinion on this as well (add sr-dev on CC).

Best regards,

Henning


-- 
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
Kamailio security assessment - https://skalatan.de/de/assessment

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


Re: [SR-Users] Kamailio TOPOS fail

2019-02-11 Thread Marcos Pytel
Do you have TOPOS enabled in yours systems?

 

Regards,
Marcos.

 

De: sr-users  En nombre de Julien Chavanton
Enviado el: lunes 11 de febrero del 2019 14:53
Para: Kamailio (SER) - Users Mailing List 
Asunto: Re: [SR-Users] Kamailio TOPOS fail

 

Thanks updated the issue with the link

 

On Mon, Feb 11, 2019 at 9:50 AM Daniel Tryba mailto:d.tr...@pocos.nl> > wrote:

On Mon, Feb 11, 2019 at 09:07:04AM -0800, Julien Chavanton wrote:
> Hi Marco, not sure if it is the same issue, but I am looking at a problem I
> am facing where in-dialog requests are failing after 3 minutes.
> 
> It seems you are also using topos_redis
> 
> Tracing TOPOS traffic is seems some leg related infomation is set to expire
> after 3 minutes.
> 

Noticed this a long time ago, apparantly never made a bug report:
https://lists.kamailio.org/pipermail/sr-users/2018-March/100835.html



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

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


[SR-Users] Repository for automatic deployment of Kamailio

2019-02-11 Thread Gholamreza Sabery
Hi,

A few years ago, I developed an Ansible repository for automatic deployment
of Kamailio. Recently, I added some new features, and now you can deploy
the playbooks on Docker containers. I think it is a good starting point for
anyone who wants to deploy and use Kamailio for the first time. Link of the
repository:

https://github.com/ghrst/Kamailio-HA

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


Re: [SR-Users] Kamailio TOPOS fail

2019-02-11 Thread Julien Chavanton
Thanks updated the issue with the link

On Mon, Feb 11, 2019 at 9:50 AM Daniel Tryba  wrote:

> On Mon, Feb 11, 2019 at 09:07:04AM -0800, Julien Chavanton wrote:
> > Hi Marco, not sure if it is the same issue, but I am looking at a
> problem I
> > am facing where in-dialog requests are failing after 3 minutes.
> >
> > It seems you are also using topos_redis
> >
> > Tracing TOPOS traffic is seems some leg related infomation is set to
> expire
> > after 3 minutes.
> >
>
> Noticed this a long time ago, apparantly never made a bug report:
> https://lists.kamailio.org/pipermail/sr-users/2018-March/100835.html
>
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Kamailio TOPOS fail

2019-02-11 Thread Daniel Tryba
On Mon, Feb 11, 2019 at 09:07:04AM -0800, Julien Chavanton wrote:
> Hi Marco, not sure if it is the same issue, but I am looking at a problem I
> am facing where in-dialog requests are failing after 3 minutes.
> 
> It seems you are also using topos_redis
> 
> Tracing TOPOS traffic is seems some leg related infomation is set to expire
> after 3 minutes.
> 

Noticed this a long time ago, apparantly never made a bug report:
https://lists.kamailio.org/pipermail/sr-users/2018-March/100835.html



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


Re: [SR-Users] Kamailio TOPOS fail

2019-02-11 Thread Julien Chavanton
Hi Marco, not sure if it is the same issue, but I am looking at a problem I
am facing where in-dialog requests are failing after 3 minutes.

It seems you are also using topos_redis

Tracing TOPOS traffic is seems some leg related infomation is set to expire
after 3 minutes.

Just sharing in case we can get a quick answer, but I will troubleshoot the
behavior more to understand if this is suppose to be transaction data that
and Dialog data should persist anyway.
Seems like 2 EXPIRE commands are sent, the second one with a low value of
180

https://github.com/kamailio/kamailio/issues/1848



On Mon, Feb 11, 2019 at 3:38 AM Marcos Pytel 
wrote:

> Hi all!
>
> Any clue for this?
>
> Marcos.
> -Mensaje original-
> De: Henning Westerholt 
> Enviado el: martes 5 de febrero del 2019 17:50
> Para: sr-users@lists.kamailio.org
> CC: Marcos Pytel 
> Asunto: Re: [SR-Users] Kamailio TOPOS fail
>
> Am Montag, 4. Februar 2019, 17:11:03 CET schrieb Marcos Pytel:
> > When I activate the TOPOS function, the Kamailio lb fail.
> >
> > This is the traceback
>
> Hello Marcos,
>
> thank you for the report. the best is to open an issue on our github
> tracker
> about this, to better tackle it. Please include more information (you'll
> find pointers there in the template).
>
> Best regards,
>
> Henning
>
> > Program terminated with signal SIGABRT, Aborted.
> >
> > #0  __GI_raise (sig=sig@entry=6) at
> > ../sysdeps/unix/sysv/linux/raise.c:51
> >
> > 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> >
> > (gdb) backtrace
> >
> > #0  __GI_raise (sig=sig@entry=6) at
> > ../sysdeps/unix/sysv/linux/raise.c:51
> >
> > #1  0x7f66d5aab42a in __GI_abort () at abort.c:89
> >
> > #2  0x7f66d5ae7c00 in __libc_message (do_abort=do_abort@entry=2,
> > fmt=fmt@entry=0x7f66d5bdb305 "*** %s ***: %s terminated\n")
> >
> > at ../sysdeps/posix/libc_fatal.c:175
> >
> > #3  0x7f66d5b701f7 in __GI___fortify_fail
> > (msg=msg@entry=0x7f66d5bdb29c "buffer overflow detected") at
> > fortify_fail.c:30
> >
> > #4  0x7f66d5b6e330 in __GI___chk_fail () at chk_fail.c:28
> >
> > #5  0x7f66b867e097 in memcpy (__len=,
> > __src= > out>, __dest=0x7f66b8892524 <_tps_redis_cbuf+4>)
> >
> > at /usr/include/x86_64-linux-gnu/bits/string3.h:53
> >
> > #6  tps_redis_load_branch (msg=, md=,
> > sd=0x7ffed3993d30, mode=) at topos_redis_storage.c:744
> >
> > #7  0x7f66b88b35c0 in tps_request_received
> > (msg=msg@entry=0x7ffed3995f80, dialog=dialog@entry=1) at tps_msg.c:786
> >
> > #8  0x7f66b88b9255 in tps_msg_received (evp=) at
> > topos_mod.c:332
> >
> > #9  0x55e1dc07da88 in sr_event_exec (type=,
> > evp=) at core/events.c:211
> >
> > #10 0x55e1dc0415f5 in receive_msg (
> >
> > buf=buf@entry=0x55e1dc511d40  "BYE
> > sip:atpsh-5c4b0f6e-25b2-9@10.10.10.2 SIP/2.0\r\nVia: SIP/2.0/UDP
> > 10.10.10.1:5060;branch=z9hG4bK898122669\r\nFrom:
> > ;tag=3296734298\r\nTo:
> > ;tag=03D2CCF0-5"..., len=381,
> > rcv_info=rcv_info@entry=0x7ffed3996980) at core/receive.c:157
> >
> > #11 0x55e1dbf5e6e3 in udp_rcv_loop () at core/udp_server.c:554
> >
> > #12 0x55e1dbef3a9f in main_loop () at main.c:1619
> >
> > #13 0x55e1dbeea8cb in main (argc=,
> > argv=0x7ffed3996f38) at main.c:2638
> >
> >
> >
> > This is a Kamailio error? I can fix it?
>
>
> --
> Henning Westerholt - https://skalatan.de/blog/ Kamailio services -
> https://skalatan.de/services Kamailio security assessment -
> https://skalatan.de/de/assessment
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] reg_fetch_contacts and t_relay usage

2019-02-11 Thread Володимир Іванець
Hello Denys,

Thanks a lot for the hint! All I had to do is to assign *addr* value for
correct contact to $ru.

пн, 11 лют. 2019 о 18:14 Denys Pozniak  пише:

> Hello!
> Try to use indexes:
>
> http://kamailio.org/docs/modules/stable/modules/registrar.html#idm1026882308
>
>
> пн, 11 февр. 2019 г. в 17:44, Володимир Іванець  >:
>
>> Hello!
>>
>> I'm using *reg_fetch_contacts* function to get information about all
>> contacts. This allows to define which contacts should receive the call. My
>> question is if it's possible to choose only one contact before *t_relay* is
>> called? Or *reg_fetch_contacts* call and verification should be done
>> after *t_relay* in all branches and those which are not needed should be
>> stopped?
>>
>> Thanks a lot!
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
>
> BR,
> Denys Pozniak
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] reg_fetch_contacts and t_relay usage

2019-02-11 Thread Denys Pozniak
Hello!
Try to use indexes:
http://kamailio.org/docs/modules/stable/modules/registrar.html#idm1026882308


пн, 11 февр. 2019 г. в 17:44, Володимир Іванець :

> Hello!
>
> I'm using *reg_fetch_contacts* function to get information about all
> contacts. This allows to define which contacts should receive the call. My
> question is if it's possible to choose only one contact before *t_relay* is
> called? Or *reg_fetch_contacts* call and verification should be done
> after *t_relay* in all branches and those which are not needed should be
> stopped?
>
> Thanks a lot!
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 

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


[SR-Users] reg_fetch_contacts and t_relay usage

2019-02-11 Thread Володимир Іванець
Hello!

I'm using *reg_fetch_contacts* function to get information about all
contacts. This allows to define which contacts should receive the call. My
question is if it's possible to choose only one contact before *t_relay* is
called? Or *reg_fetch_contacts* call and verification should be done after
*t_relay* in all branches and those which are not needed should be stopped?

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


Re: [SR-Users] Kamailio TOPOS fail

2019-02-11 Thread Marcos Pytel
Hi all!

Any clue for this?

Marcos.
-Mensaje original-
De: Henning Westerholt  
Enviado el: martes 5 de febrero del 2019 17:50
Para: sr-users@lists.kamailio.org
CC: Marcos Pytel 
Asunto: Re: [SR-Users] Kamailio TOPOS fail

Am Montag, 4. Februar 2019, 17:11:03 CET schrieb Marcos Pytel:
> When I activate the TOPOS function, the Kamailio lb fail.
> 
> This is the traceback

Hello Marcos,

thank you for the report. the best is to open an issue on our github tracker
about this, to better tackle it. Please include more information (you'll
find pointers there in the template).

Best regards,

Henning

> Program terminated with signal SIGABRT, Aborted.
> 
> #0  __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:51
> 
> 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> 
> (gdb) backtrace
> 
> #0  __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:51
> 
> #1  0x7f66d5aab42a in __GI_abort () at abort.c:89
> 
> #2  0x7f66d5ae7c00 in __libc_message (do_abort=do_abort@entry=2,
> fmt=fmt@entry=0x7f66d5bdb305 "*** %s ***: %s terminated\n")
> 
> at ../sysdeps/posix/libc_fatal.c:175
> 
> #3  0x7f66d5b701f7 in __GI___fortify_fail 
> (msg=msg@entry=0x7f66d5bdb29c "buffer overflow detected") at 
> fortify_fail.c:30
> 
> #4  0x7f66d5b6e330 in __GI___chk_fail () at chk_fail.c:28
> 
> #5  0x7f66b867e097 in memcpy (__len=, 
> __src= out>, __dest=0x7f66b8892524 <_tps_redis_cbuf+4>)
> 
> at /usr/include/x86_64-linux-gnu/bits/string3.h:53
> 
> #6  tps_redis_load_branch (msg=, md=, 
> sd=0x7ffed3993d30, mode=) at topos_redis_storage.c:744
> 
> #7  0x7f66b88b35c0 in tps_request_received 
> (msg=msg@entry=0x7ffed3995f80, dialog=dialog@entry=1) at tps_msg.c:786
> 
> #8  0x7f66b88b9255 in tps_msg_received (evp=) at
> topos_mod.c:332
> 
> #9  0x55e1dc07da88 in sr_event_exec (type=, 
> evp=) at core/events.c:211
> 
> #10 0x55e1dc0415f5 in receive_msg (
> 
> buf=buf@entry=0x55e1dc511d40  "BYE
> sip:atpsh-5c4b0f6e-25b2-9@10.10.10.2 SIP/2.0\r\nVia: SIP/2.0/UDP
> 10.10.10.1:5060;branch=z9hG4bK898122669\r\nFrom:
> ;tag=3296734298\r\nTo:
> ;tag=03D2CCF0-5"..., len=381,
> rcv_info=rcv_info@entry=0x7ffed3996980) at core/receive.c:157
> 
> #11 0x55e1dbf5e6e3 in udp_rcv_loop () at core/udp_server.c:554
> 
> #12 0x55e1dbef3a9f in main_loop () at main.c:1619
> 
> #13 0x55e1dbeea8cb in main (argc=, 
> argv=0x7ffed3996f38) at main.c:2638
> 
> 
> 
> This is a Kamailio error? I can fix it?


--
Henning Westerholt - https://skalatan.de/blog/ Kamailio services -
https://skalatan.de/services Kamailio security assessment -
https://skalatan.de/de/assessment


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


Re: [SR-Users] rtpengine not listening on specified port range

2019-02-11 Thread Narayan P
Thank you Iman.

It is working now.

Thanks,
Narayan

From: sr-users  on behalf of Iman 
Mohammadi 
Sent: Monday, February 11, 2019 7:52 AM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] rtpengine not listening on specified port range

Hi

You can set your params in rtpengine.conf and run it as "rtpengine 
--config-file /directory/rtpengine.conf", you can find rtpengine.conf.sample at 
/your rtpengine directory/etc/


On Mon, Feb 11, 2019 at 10:56 AM Narayan P 
mailto:narayan...@outlook.com>> wrote:
Hello,

I am starting the rtpengine through this command,but rtpengine is not listening 
on the specified port range.It is listening on some other port outside of 
this.Here first IP is private IP and the second IP is public one.So issue is 
with audio.Can you please let me know what exactly I am missing.

rtpengine --interface=172.20.xx.xxx\!34.209.1.xx -f -m 16384 -M 16884 -E 
--listen-ng=127.0.0.1:2 &

Any suggestion will be highly appreciated.


Thanks,
Narayan
NP


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


Re: [SR-Users] trace sip msg topos

2019-02-11 Thread Daniel Tryba
On Fri, Feb 08, 2019 at 11:08:03AM -0800, Julien Chavanton wrote:
> The solution that worked for me was to use :
> 
> trace_mode=1
> 
> This is capturing both version of the message, I think  this is about using
> a core event hook instead of a transaction callback

Although this is not the solution Guissepe is looking for (he wants to
log local to syslog). siptrace/HEP/homer is a great tool to log any
message and have a decent interface to search them.


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