date:20180410

Re: [SR-Users] ims_dialog default_timeout parameter

2018-04-10 Thread tyd

Hello,
>
> there are a lot of active dialogs there, however, as they BYEs are
> replied, the structures should be released in short time and shared memory
> freed. Do you execute dlg_manage() when receiving BYE?
>
> Cheers,
> Daniel
>
Hello,

I can not find dlg_manage in example scscf configuration file.
But below is ims_dialog document, dlg_manager has been deprecated in
ims_dialog.
6.10.  dlg_manage()

This has been deprecated in ims_dialog. Instead set dialog flag for initial
INVITE and Route-parameter-callback execution for within-dialog requests.

Any suggestions? Thanks.




> On 10.04.18 10:43, tyd wrote:
>
>
>
> Hello,
>>
>> do you get also dialog statistics? tm stats are not relevant in this
>> context.
>>
>> Cheers,
>> Daniel
>>
> Hi,
>
> I'm re-running SIPp.
> The share memory is decreaing and will run out of memory.
> Is below information enough ?
>
>
> # kamctl stats shmem
> shmem:fragments = 40
> shmem:free_size = 312842424
> shmem:max_used_size = 224156616
> shmem:real_used_size = 224028488
> shmem:total_size = 536870912
> shmem:used_size = 140091536
>
> #kamctl mi dlg_list|grep dialog|wc -l
> 121500
>
> # kamctl dialog show|grep dialog|wc -l
> 123363
>
> # kamctl fifo get_statistics :dialog::all
> cdp:average_response_time = 3
> cdp:queuelength = 0
> cdp:replies_received = 2
> cdp:replies_response_time = 72658
> cdp:timeout = 0
> core:bad_URIs_rcvd = 0
> core:bad_msg_hdr = 0
> core:drop_replies = 0
> core:drop_requests = 0
> core:err_replies = 0
> core:err_requests = 0
> core:fwd_replies = 0
> core:fwd_requests = 122460
> core:rcv_replies = 548443
> core:rcv_requests = 384642
> core:unsupported_methods = 0
> dialog_ng:active = 61230
> dialog_ng:early = 37
> dialog_ng:expired = 0
> dialog_ng:processed = 61267
> dns:failed_dns_request = 0
> ims_auth:mar_avg_response_time = 1
> ims_auth:mar_replies_received = 1
> ims_auth:mar_replies_response_time = 16199
> ims_auth:mar_timeouts = 0
> ims_registrar_scscf:accepted_regs = 1
> ims_registrar_scscf:default_expire = 3660
> ims_registrar_scscf:default_expires_range = 0
> ims_registrar_scscf:max_contacts = 1
> ims_registrar_scscf:max_expires = 654800
> ims_registrar_scscf:rejected_regs = 0
> ims_registrar_scscf:sar_avg_response_time = 5
> ims_registrar_scscf:sar_replies_received = 1
> ims_registrar_scscf:sar_replies_response_time = 56459
> ims_registrar_scscf:sar_timeouts = 0
> ims_usrloc_scscf:active_contacts = 1
> ims_usrloc_scscf:active_impus = 1
> ims_usrloc_scscf:active_subscriptions = 1
> ims_usrloc_scscf:contact_collisions = 28
> ims_usrloc_scscf:impu_collisions = 27
> ims_usrloc_scscf:subscription_collisions = 27
> mysql:driver_errors = 0
> shmem:fragments = 30
> shmem:free_size = 311718120
> shmem:max_used_size = 225269176
> shmem:real_used_size = 225152792
> shmem:total_size = 536870912
> shmem:used_size = 140599664
> sl:1xx_replies = 0
> sl:200_replies = 0
> sl:202_replies = 0
> sl:2xx_replies = 0
> sl:300_replies = 0
> sl:301_replies = 0
> sl:302_replies = 0
> sl:3xx_replies = 0
> sl:400_replies = 0
> sl:401_replies = 0
> sl:403_replies = 0
> sl:404_replies = 0
> sl:407_replies = 0
> sl:408_replies = 0
> sl:483_replies = 0
> sl:4xx_replies = 0
> sl:500_replies = 0
> sl:5xx_replies = 0
> sl:6xx_replies = 0
> sl:failures = 0
> sl:received_ACKs = 0
> sl:sent_err_replies = 0
> sl:sent_replies = 122534
> sl:xxx_replies = 122534
> tcp:con_reset = 0
> tcp:con_timeout = 0
> tcp:connect_failed = 0
> tcp:connect_success = 0
> tcp:current_opened_connections = 0
> tcp:current_write_queue_size = 0
> tcp:established = 0
> tcp:local_reject = 0
> tcp:passive_open = 0
> tcp:send_timeout = 0
> tcp:sendq_full = 0
>
> #
>
>
>
>>
>> On 10.04.18 09:19, tyd wrote:
>>
>> Hello,
>>>
>>> On 10.04.18 07:25, tyd wrote:
>>>
>>> Hi, Daniel
>>>
>>> No, the dialogs were not terminated after 10 minutes if no BYE message
>>> was sent.
>>>
>>>
>>> Not using ims_dialog, but it may be that it doesn't send bye when the
>>> dialog lifetime elapses, just destroys the structure it keeps in memory.
>>> With the other dialog module, there is a parameter to set if you want BYE
>>> to be sent.
>>>
>>> But if Default value(43200) was set,  the S-CSCF will run out of memory
>>> finally (after 20 calls).
>>>
>>> Were all these calls still active?
>>>
>>> Hi,
>> In SIPp, the calls were finishes.
>> But in Kamailio, the calls seem keep in the memory and run out of memory.
>> Can any parameter solve this problem?
>> Is it  a solution  to set "ims_dialog", "default_timeout" to  600 ?
>>
>> # kamcmd tm.stats
>> {
>> current: 69
>> waiting: 0
>> total: 991300
>> total_local: 0
>> rpl_received: 2183891
>> rpl_generated: 20232
>> rpl_sent: 1475856
>> 6xx: 0
>> 5xx: 2704
>> 4xx: 10124
>> 3xx: 0
>> 2xx: 978329
>> created: 991300
>> freed: 991231
>> delayed_free: 0
>> }
>> # kamctl stats shmem
>> shmem:fragments = 1630
>> shmem:free_size = 4303040

Re: [SR-Users] no corresponding socket found for

2018-04-10 Thread Kjeld Flarup


Hi Daniel

I was actually using

kamailio:5069 lookup() => 12345678@kamailio:5070 forward() => 
kamailio:5071 t_relay()

    u1@kamailio:5070 (404)

I thus tried to change forward() to t_relay(), but then I found that the 
call was cancelled. Removing all 404 reply generations in the system, 
made my call get through.


It seems that lookup() branched the call, and the "u1" branch in 
kamailio:5070 generated a 404 back to kamailio:5069, but also a cancel 
to kamailio:5071. The cancel to kamailio:5071 was however for the u1 
branch and not the 12345678 branch. But the callid was the same!



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 04/10/2018 10:49 AM, Daniel-Constantin Mierla wrote:


Looks like the socket used for sending out is the loopback address and 
thus cannot send to 192.168.2.101.


Do you use t_relay() for forwarding the request?

Cheers,
Daniel


On 10.04.18 10:08, Kjeld Flarup wrote:

Listening is configured like this:

#!define LOCALIP 192.168.2.9
#!subst "/LOCALIP/192.168.2.9/g "
listen=127.0.0.1:5069 
listen=LOCALIP:5069


Kjeld

2018-04-10 9:43 GMT+02:00 Daniel-Constantin Mierla >:


Hello,

is the instance throwing the error listening only on 127.0.0.1
address?

Cheers,
Daniel


On 09.04.18 23:54, Kjeld Flarup wrote:


Hi

I have a setup with three kamailio's in the same host but on
different ports. client ->5069 -> 5070 -> 5071 -> SIP provider

Now I get this error from the 5069 Kamailio when it is routing a
200 Ok to the client:

Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
[forward.c:181]: get_out_socket(): no socket found
Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
[forward.c:183]: get_out_socket(): no corresponding socket found
for(udp:192.168.2.101:10120 )
Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
[forward.c:808]: do_forward_reply(): cannot forward reply

By manipulating the database I can skip the 5070 Kamailio, and
then it works.

I captured these two 200 Ok packets to the 5069 kamailio

*Failing:*

No. Time Source    Destination Protocol Length Info
   4713 21:54:12.814245 127.0.0.1 127.0.0.1 SIP/SDP 
2297   Status: 200 OK |

Frame 4713: 2297 bytes on wire (18376 bits), 2297 bytes captured
(18376 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
User Datagram Protocol, Src Port: 5070, Dst Port: 5069
Session Initiation Protocol (200)
    Status-Line: SIP/2.0 200 OK
    Message Header
    Via: SIP/2.0/UDP

127.0.0.1:5069;rport=5069;branch=z9hG4bK6ef1.0c009dcf5b4965c5d1a13d508e0b31c5.0
    Via: SIP/2.0/UDP

192.168.2.101:10120;received=192.168.2.101;rport=10120;branch=z9hG4bKPjIq.uY6jYbHkIqCo03bYLsTzccb7oy9jw
    Record-Route:

    Record-Route:


    Record-Route:


    Record-Route:


    Record-Route:


    Record-Route:


    Record-Route:


    Record-Route:


    Record-Route:


    From: "Door" 
;tag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW
    To: 
;tag=1865008112
    Call-ID: ou8V0cLHn.P7Oca-pgsnMmrWO43kIQX8
    CSeq: 5778 INVITE
    Contact:


    Allow:
INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE

Re: [SR-Users] rtpengine no voice when working between DTLS-SRTP endpoints

2018-04-10 Thread Aqs Younas

Sometimes, I see below logs in RTP engine.


Apr 10 17:59:21 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: Received command 'answer' from
127.0.0.1:44933
Apr 10 17:59:21 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: answer time = 0.000163 sec
Apr 10 17:59:21 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: Replying to 'answer' from
127.0.0.1:44933
[1523383161.279950] ERR: [24b95195-3da3-4e12-8400-5fcf908183e5 port  8268]:
SRTP output wanted, but no crypto suite was negotiated
Apr 10 17:59:21 centos-1024mb-nyc-02 rtpengine[65101]: ERR:
[24b95195-3da3-4e12-8400-5fcf908183e5 port  8268]: SRTP output wanted, but
no crypto suite was negotiated
Apr 10 17:59:25 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5 port  8268]: Confirmed peer address
as 72.214.35.171:64834
[1523383171.481023] ERR: [24b95195-3da3-4e12-8400-5fcf908183e5 port  8269]:
SRTCP output wanted, but no crypto suite was negotiated
Apr 10 17:59:31 centos-1024mb-nyc-02 rtpengine[65101]: ERR:
[24b95195-3da3-4e12-8400-5fcf908183e5 port  8269]: SRTCP output wanted, but
no crypto suite was negotiated
Apr 10 17:59:31 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5 port  8269]: Confirmed peer address
as 72.214.35.171:50108
[1523383176.025296] ERR: [24b95195-3da3-4e12-8400-5fcf908183e5 port  8268]:
SRTP output wanted, but no crypto suite was negotiated
Apr 10 17:59:36 centos-1024mb-nyc-02 rtpengine[65101]: ERR:
[24b95195-3da3-4e12-8400-5fcf908183e5 port  8268]: SRTP output wanted, but
no crypto suite was negotiated
[1523383186.000280] ERR: [02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS
error: 1 (read timeout expired)
[1523383186.000335] ERR: [02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS error
on local port 8248
[1523383186.000419] ERR: [02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS
error: 1 (read timeout expired)
[1523383186.000429] ERR: [02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS error
on local port 8249
*Apr 10 17:59:46 centos-1024mb-nyc-02 rtpengine[65101]: ERR:
[02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS error: 1 (read timeout
expired)*
*Apr 10 17:59:46 centos-1024mb-nyc-02 rtpengine[65101]: ERR:
[02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS error on local port 8248*
*Apr 10 17:59:46 centos-1024mb-nyc-02 rtpengine[65101]: ERR:
[02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS error: 1 (read timeout
expired)*
*Apr 10 17:59:46 centos-1024mb-nyc-02 rtpengine[65101]: ERR:
[02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS error on local port 8249*
*Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: Closing call due to timeout*
Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: Final packet stats:
Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: --- Tag
'f6d2237d-f960-4542-b138-f39a7fb52770', created 1:32 ago for branch '', in
dialogue with '6bdf30d1-2da6-4b6d-b917-aaa720c9c1fa'
Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: -- Media #1 (audio over
UDP/TLS/RTP/SAVP) using unknown codec
*Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: - Port  209.182.216.71:8288
  <>  100.84.103.245:4002
 , SSRC 0, 0 p, 0 b, 0 e, 92 ts*
*Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: - Port  209.182.216.71:8289
  <>  100.84.103.245:4003
  (RTCP), SSRC 0, 0 p, 0 b, 0 e, 92 ts*
Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: --- Tag
'6bdf30d1-2da6-4b6d-b917-aaa720c9c1fa', created 1:32 ago for branch '', in
dialogue with 'f6d2237d-f960-4542-b138-f39a7fb52770'
Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: -- Media #1 (audio over
UDP/TLS/RTP/SAVP) using G722/8000
Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: - Port  209.182.216.71:8268
<>   72.214.35.171:64834, SSRC 653128b4, 935 p, 160820 b, 0 e, 60 ts
Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO:
[24b95195-3da3-4e12-8400-5fcf908183e5]: - Port  209.182.216.71:8269
<>   72.214.35.171:50108 (RTCP), SSRC 653128b4, 3 p, 278 b, 0 e, 60 ts


Any suggestion what might be happening?

Br, Aqs.

On 10 April 2018 at 22:59, Aqs Younas  wrote:

> I could see SRTP packets coming from one device but they never leave
> rtpeninge.
>
> I put a link to Pastebin containing a call trace with the hope that
> someone might help me out.
>
> I could provide more info if required.
>
> https://pastebin.com/tYVpFQAh
>
> Br, Aqs.
>
>
> On

Re: [SR-Users] Kamailio ds_ping_interval Performance

2018-04-10 Thread Jurijs Ivolga

Hi,

Please check how SIP works, but as far as I remember if Kamailio gets 200
from Freeswitch #2, it will send cancell to all other branches.

With kind regards,

Jurijs

On Tue, Apr 10, 2018 at 9:01 AM, Atul Thosar  wrote:

> Any pointers, suggestions.
>
> --
> Thanks,
> Atul Thosar
>
>
>
> On 8 April 2018 at 17:23, Atul Thosar  wrote:
>
>> Thanks all for your responses.
>>
>>
>> I am new to Kamailio, so appreciate if some one can help me with sample
>> code where kamailio routes call to another FreeSWITCH server if 1st
>> FreeSWITCH server does not respond in some time, say 3 sec. Btw I have a
>> query on this approach. Consider a following scenario -
>>
>> 0. kamailio is configured w/ 2 FreeSWITCH servers in dispatcher and with
>> configuration where on not receiving response to INVITE in 3 sec, kamailio
>> will forward the call to another FreeSWITCH server.
>> 1. kamailio receives INVITE and forwards INVITE to FreeSWITCH #1
>> 2. FreeSWITCH #1 receives INVITE, but 100 trying response could not reach
>> to kamailio bec of network break, say for 4 sec.
>> 3. So After 3 sec, since kamailio does not receive any response from
>> FreeSWITCH #1, it forwards INVITE to FreeSWITCH #2
>> 4. FreeSWITCH #2 responds with 200 OK and kamailio receives it.
>> 5. After 4 sec, when network recovers, FreeSWITCH #1 sends 200 OK to
>> kamailio. How kamailio would behave here? Will it drops the call w/
>> FreeSWITCH #1?
>>
>>
>> --
>> Thanks,
>> Atul Thosar
>>
>>
>>
>> On 7 April 2018 at 21:46, Julien Chavanton  wrote:
>>
>>> Hi,
>>>
>>> I would set it to a low value to make sure you avoid sending calls a
>>> Freeswitch server facing problems, in the case of Freeswitch the same GW
>>> will also handle media, if it is having hardtime repliyng to SIP OPTIONS it
>>> will very likely have problem handling the media.
>>>
>>> It may also get worst during the call even stop responsding and loose
>>> transaction in progress or in dialog transactions later like session timers
>>> and BYEs.
>>>
>>> Off loading it may able help other calls already using it.
>>>
>>>
>>> You may push your strategy further thinking about :
>>>
>>> - The risk is that you run out of GW, could be handled when ds_select is
>>> returning nothing.
>>> - Another side effect, would be that you are sending more traffic to
>>> other GW, they must be able to handle the extra load.
>>>
>>> In kamailio 5 there is a new algorithm that behaves better when one GW
>>> is put out of service.
>>>
>>> “11” - use relative weight based load distribution. You have to set the
>>> attribute 'rweight' per each address in destination set. Active host usage
>>> probability is rweight/(SUM of all active host rweights in destination
>>> group).
>>>
>>> Regards
>>> Julien
>>>
>>> On Mon, Apr 2, 2018 at 6:06 PM, Atul Thosar 
>>> wrote:
>>>
 Hi All,
 I am using Kamailio
 **
 *v4.4.x* to load balanced traffic to FreeSWITCH servers. I have query
 regarding ds_ping_interval and ds_probing_threshold. We have very high
 traffic (around 200-400
  (CPS)
 calls per sec) hitting on Kamailio which then distribute it to 2-3
 FreeSWITCH servers.
  
 What is the optimal value should I set to ds_ping_interval and
 ds_probing_threshold?

 If I set
 
 ds_ping_interval=2 and
 
 ds_probing_threshold=1 then in every 2 sec, I would come to know if my
 
 FreeSWITCH server is down/up. But by setting such low values, I afraid
 there would
 be 
 lot of SIP traffic on network.
  If I set high (say
 
 ds_probing_threshold=5) then I may loose high number of calls (200 CPS,
 I will loose 1000 calls) in case
 
 FreeSWITCH server is down. 


 As I said earlier we have very high traffic hitting on Kamailio, can't
 kamailio use INVITE itself to probe FreeSWITCH server is down/up? In case
 of low traffic can't it switch over to OPTION mechanism?

 --
 Thanks in Advance
 ,
 
 Atul
 
 
 



 ___
 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
>>>
>>>
>>
>
> ___
> 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] ims_dialog default_timeout parameter

2018-04-10 Thread Daniel-Constantin Mierla

Hello,

there are a lot of active dialogs there, however, as they BYEs are
replied, the structures should be released in short time and shared
memory freed. Do you execute dlg_manage() when receiving BYE?

Cheers,
Daniel


On 10.04.18 10:43, tyd wrote:
>
>
> Hello,
>
> do you get also dialog statistics? tm stats are not relevant in
> this context.
>
> Cheers,
> Daniel
>
> Hi,
>
> I'm re-running SIPp.
> The share memory is decreaing and will run out of memory.
> Is below information enough ?
>
>
> # kamctl stats shmem
> shmem:fragments = 40
> shmem:free_size = 312842424
> shmem:max_used_size = 224156616
> shmem:real_used_size = 224028488
> shmem:total_size = 536870912
> shmem:used_size = 140091536
>
> #kamctl mi dlg_list|grep dialog|wc -l
> 121500
>
> # kamctl dialog show|grep dialog|wc -l
> 123363
>
> # kamctl fifo get_statistics :dialog::all
> cdp:average_response_time = 3
> cdp:queuelength = 0
> cdp:replies_received = 2
> cdp:replies_response_time = 72658
> cdp:timeout = 0
> core:bad_URIs_rcvd = 0
> core:bad_msg_hdr = 0
> core:drop_replies = 0
> core:drop_requests = 0
> core:err_replies = 0
> core:err_requests = 0
> core:fwd_replies = 0
> core:fwd_requests = 122460
> core:rcv_replies = 548443
> core:rcv_requests = 384642
> core:unsupported_methods = 0
> dialog_ng:active = 61230
> dialog_ng:early = 37
> dialog_ng:expired = 0
> dialog_ng:processed = 61267
> dns:failed_dns_request = 0
> ims_auth:mar_avg_response_time = 1
> ims_auth:mar_replies_received = 1
> ims_auth:mar_replies_response_time = 16199
> ims_auth:mar_timeouts = 0
> ims_registrar_scscf:accepted_regs = 1
> ims_registrar_scscf:default_expire = 3660
> ims_registrar_scscf:default_expires_range = 0
> ims_registrar_scscf:max_contacts = 1
> ims_registrar_scscf:max_expires = 654800
> ims_registrar_scscf:rejected_regs = 0
> ims_registrar_scscf:sar_avg_response_time = 5
> ims_registrar_scscf:sar_replies_received = 1
> ims_registrar_scscf:sar_replies_response_time = 56459
> ims_registrar_scscf:sar_timeouts = 0
> ims_usrloc_scscf:active_contacts = 1
> ims_usrloc_scscf:active_impus = 1
> ims_usrloc_scscf:active_subscriptions = 1
> ims_usrloc_scscf:contact_collisions = 28
> ims_usrloc_scscf:impu_collisions = 27
> ims_usrloc_scscf:subscription_collisions = 27
> mysql:driver_errors = 0
> shmem:fragments = 30
> shmem:free_size = 311718120
> shmem:max_used_size = 225269176
> shmem:real_used_size = 225152792
> shmem:total_size = 536870912
> shmem:used_size = 140599664
> sl:1xx_replies = 0
> sl:200_replies = 0
> sl:202_replies = 0
> sl:2xx_replies = 0
> sl:300_replies = 0
> sl:301_replies = 0
> sl:302_replies = 0
> sl:3xx_replies = 0
> sl:400_replies = 0
> sl:401_replies = 0
> sl:403_replies = 0
> sl:404_replies = 0
> sl:407_replies = 0
> sl:408_replies = 0
> sl:483_replies = 0
> sl:4xx_replies = 0
> sl:500_replies = 0
> sl:5xx_replies = 0
> sl:6xx_replies = 0
> sl:failures = 0
> sl:received_ACKs = 0
> sl:sent_err_replies = 0
> sl:sent_replies = 122534
> sl:xxx_replies = 122534
> tcp:con_reset = 0
> tcp:con_timeout = 0
> tcp:connect_failed = 0
> tcp:connect_success = 0
> tcp:current_opened_connections = 0
> tcp:current_write_queue_size = 0
> tcp:established = 0
> tcp:local_reject = 0
> tcp:passive_open = 0
> tcp:send_timeout = 0
> tcp:sendq_full = 0
>
> #
>
>  
>
>
> On 10.04.18 09:19, tyd wrote:
>>
>> Hello,
>>
>>
>> On 10.04.18 07:25, tyd wrote:
>>> Hi, Daniel
>>>
>>> No, the dialogs were not terminated after 10 minutes if no
>>> BYE message was sent.
>>
>> Not using ims_dialog, but it may be that it doesn't send bye
>> when the dialog lifetime elapses, just destroys the structure
>> it keeps in memory. With the other dialog module, there is a
>> parameter to set if you want BYE to be sent.
>>> But if Default value(43200) was set,  the S-CSCF will run
>>> out of memory finally (after 20 calls).
>> Were all these calls still active?
>>
>> Hi,
>> In SIPp, the calls were finishes.
>> But in Kamailio, the calls seem keep in the memory and run out of
>> memory.
>> Can any parameter solve this problem? 
>> Is it  a solution  to set "ims_dialog", "default_timeout" to  600 ?
>> # kamcmd tm.stats
>> {
>> current: 69
>> waiting: 0
>> total: 991300
>> total_local: 0
>> rpl_received: 2183891
>> rpl_generated: 20232
>> rpl_sent: 1475856
>> 6xx: 0
>> 5xx: 2704
>> 4xx: 10124
>> 3xx: 0
>> 2xx: 978329
>> created: 991300
>> freed: 991231
>> delayed_free: 0
>> }
>> # kamctl stats shmem
>> shmem:fragments = 1630
>> shmem:free_size = 4303040
>> shmem:max_used_size = 536870912
>> shmem:real_used_size = 532567872
>> shmem:total_size = 536870912
>> shmem:used_size = 415668000
>>  
>>

Re: [SR-Users] no corresponding socket found for

2018-04-10 Thread Daniel-Constantin Mierla

Looks like the socket used for sending out is the loopback address and
thus cannot send to 192.168.2.101.

Do you use t_relay() for forwarding the request?

Cheers,
Daniel


On 10.04.18 10:08, Kjeld Flarup wrote:
> Listening is configured like this:
>
> #!define LOCALIP 192.168.2.9
> #!subst "/LOCALIP/192.168.2.9/g "
> listen=127.0.0.1:5069  
> listen=LOCALIP:5069
>
>
> Kjeld
>
> 2018-04-10 9:43 GMT+02:00 Daniel-Constantin Mierla  >:
>
> Hello,
>
> is the instance throwing the error listening only on 127.0.0.1
> address?
>
> Cheers,
> Daniel
>
>
> On 09.04.18 23:54, Kjeld Flarup wrote:
>>
>> Hi
>>
>> I have a setup with three kamailio's in the same host but on
>> different ports. client ->5069 -> 5070 -> 5071 -> SIP provider
>>
>> Now I get this error from the 5069 Kamailio when it is routing a
>> 200 Ok to the client:
>>
>> Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
>> [forward.c:181]: get_out_socket(): no socket found
>> Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
>> [forward.c:183]: get_out_socket(): no corresponding socket found
>> for(udp:192.168.2.101:10120 )
>> Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
>> [forward.c:808]: do_forward_reply(): cannot forward reply
>>
>> By manipulating the database I can skip the 5070 Kamailio, and
>> then it works.
>>
>> I captured these two 200 Ok packets to the 5069 kamailio
>>
>> *Failing:*
>>
>> No. Time   Source   
>> Destination   Protocol Length Info
>>    4713 21:54:12.814245    127.0.0.1
>> 127.0.0.1 SIP/SDP  2297   Status: 200 OK |
>>
>> Frame 4713: 2297 bytes on wire (18376 bits), 2297 bytes captured
>> (18376 bits)
>> Linux cooked capture
>> Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
>> User Datagram Protocol, Src Port: 5070, Dst Port: 5069
>> Session Initiation Protocol (200)
>>     Status-Line: SIP/2.0 200 OK
>>     Message Header
>>     Via: SIP/2.0/UDP
>> 
>> 127.0.0.1:5069;rport=5069;branch=z9hG4bK6ef1.0c009dcf5b4965c5d1a13d508e0b31c5.0
>>     Via: SIP/2.0/UDP
>> 
>> 192.168.2.101:10120;received=192.168.2.101;rport=10120;branch=z9hG4bKPjIq.uY6jYbHkIqCo03bYLsTzccb7oy9jw
>>     Record-Route:
>> 
>>     Record-Route:
>> 
>> 
>>     Record-Route:
>> 
>> 
>>     Record-Route:
>> 
>> 
>>     Record-Route:
>> 
>> 
>>     Record-Route:
>> 
>> 
>>     Record-Route:
>> 
>> 
>>     Record-Route:
>> 
>> 
>>     Record-Route:
>> 
>> 
>>     From: "Door" 
>> ;tag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW
>>     To: 
>> ;tag=1865008112
>>     Call-ID: ou8V0cLHn.P7Oca-pgsnMmrWO43kIQX8
>>     CSeq: 5778 INVITE
>>     Contact:
>> 
>> 
>>     Allow:
>> INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE
>>     P-AS-Response: 40294149
>>     Content-Type: application/sdp
>>     Content-Length: 499
>>     Message Body
>>
>> *OK (Without 5070)*
>>
>> No. Time   Source   
>> Destination   Protocol Length Info
>>     373 21:44:42.955075    127.0.0.1
>> 127.0.0.1 SIP/SDP  2199   Status: 200 OK |
>>
>> Frame 373: 2199 bytes on wire (17592 bits), 2199 bytes captured
>> (17592 bits)
>> Linux cooked capture
>> Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
>> User Datagram Protocol, Src Port: 5071, Dst Port: 5069
>> Session

Re: [SR-Users] ims_dialog default_timeout parameter

2018-04-10 Thread tyd

Hello,
>
> do you get also dialog statistics? tm stats are not relevant in this
> context.
>
> Cheers,
> Daniel
>
Hi,

I'm re-running SIPp.
The share memory is decreaing and will run out of memory.
Is below information enough ?


# kamctl stats shmem
shmem:fragments = 40
shmem:free_size = 312842424
shmem:max_used_size = 224156616
shmem:real_used_size = 224028488
shmem:total_size = 536870912
shmem:used_size = 140091536

#kamctl mi dlg_list|grep dialog|wc -l
121500

# kamctl dialog show|grep dialog|wc -l
123363

# kamctl fifo get_statistics :dialog::all
cdp:average_response_time = 3
cdp:queuelength = 0
cdp:replies_received = 2
cdp:replies_response_time = 72658
cdp:timeout = 0
core:bad_URIs_rcvd = 0
core:bad_msg_hdr = 0
core:drop_replies = 0
core:drop_requests = 0
core:err_replies = 0
core:err_requests = 0
core:fwd_replies = 0
core:fwd_requests = 122460
core:rcv_replies = 548443
core:rcv_requests = 384642
core:unsupported_methods = 0
dialog_ng:active = 61230
dialog_ng:early = 37
dialog_ng:expired = 0
dialog_ng:processed = 61267
dns:failed_dns_request = 0
ims_auth:mar_avg_response_time = 1
ims_auth:mar_replies_received = 1
ims_auth:mar_replies_response_time = 16199
ims_auth:mar_timeouts = 0
ims_registrar_scscf:accepted_regs = 1
ims_registrar_scscf:default_expire = 3660
ims_registrar_scscf:default_expires_range = 0
ims_registrar_scscf:max_contacts = 1
ims_registrar_scscf:max_expires = 654800
ims_registrar_scscf:rejected_regs = 0
ims_registrar_scscf:sar_avg_response_time = 5
ims_registrar_scscf:sar_replies_received = 1
ims_registrar_scscf:sar_replies_response_time = 56459
ims_registrar_scscf:sar_timeouts = 0
ims_usrloc_scscf:active_contacts = 1
ims_usrloc_scscf:active_impus = 1
ims_usrloc_scscf:active_subscriptions = 1
ims_usrloc_scscf:contact_collisions = 28
ims_usrloc_scscf:impu_collisions = 27
ims_usrloc_scscf:subscription_collisions = 27
mysql:driver_errors = 0
shmem:fragments = 30
shmem:free_size = 311718120
shmem:max_used_size = 225269176
shmem:real_used_size = 225152792
shmem:total_size = 536870912
shmem:used_size = 140599664
sl:1xx_replies = 0
sl:200_replies = 0
sl:202_replies = 0
sl:2xx_replies = 0
sl:300_replies = 0
sl:301_replies = 0
sl:302_replies = 0
sl:3xx_replies = 0
sl:400_replies = 0
sl:401_replies = 0
sl:403_replies = 0
sl:404_replies = 0
sl:407_replies = 0
sl:408_replies = 0
sl:483_replies = 0
sl:4xx_replies = 0
sl:500_replies = 0
sl:5xx_replies = 0
sl:6xx_replies = 0
sl:failures = 0
sl:received_ACKs = 0
sl:sent_err_replies = 0
sl:sent_replies = 122534
sl:xxx_replies = 122534
tcp:con_reset = 0
tcp:con_timeout = 0
tcp:connect_failed = 0
tcp:connect_success = 0
tcp:current_opened_connections = 0
tcp:current_write_queue_size = 0
tcp:established = 0
tcp:local_reject = 0
tcp:passive_open = 0
tcp:send_timeout = 0
tcp:sendq_full = 0

#



>
> On 10.04.18 09:19, tyd wrote:
>
> Hello,
>>
>> On 10.04.18 07:25, tyd wrote:
>>
>> Hi, Daniel
>>
>> No, the dialogs were not terminated after 10 minutes if no BYE message
>> was sent.
>>
>>
>> Not using ims_dialog, but it may be that it doesn't send bye when the
>> dialog lifetime elapses, just destroys the structure it keeps in memory.
>> With the other dialog module, there is a parameter to set if you want BYE
>> to be sent.
>>
>> But if Default value(43200) was set,  the S-CSCF will run out of memory
>> finally (after 20 calls).
>>
>> Were all these calls still active?
>>
>> Hi,
> In SIPp, the calls were finishes.
> But in Kamailio, the calls seem keep in the memory and run out of memory.
> Can any parameter solve this problem?
> Is it  a solution  to set "ims_dialog", "default_timeout" to  600 ?
>
> # kamcmd tm.stats
> {
> current: 69
> waiting: 0
> total: 991300
> total_local: 0
> rpl_received: 2183891
> rpl_generated: 20232
> rpl_sent: 1475856
> 6xx: 0
> 5xx: 2704
> 4xx: 10124
> 3xx: 0
> 2xx: 978329
> created: 991300
> freed: 991231
> delayed_free: 0
> }
> # kamctl stats shmem
> shmem:fragments = 1630
> shmem:free_size = 4303040
> shmem:max_used_size = 536870912
> shmem:real_used_size = 532567872
> shmem:total_size = 536870912
> shmem:used_size = 415668000
>
>
>
>
>>
>> Have any relation with this parameter and memory release ?
>>
>>
>> Yes, the structure kept for each call is destroyed after lifetime. But it
>> should be also destroyed if the BYE is received.
>>
>> Cheers,
>> Daniel
>>
>>
>> Any impacts if using value 600 at production environment ?
>> Thanks.
>>
>> 2018-04-10 0:27 GMT+08:00 Daniel-Constantin Mierla :
>>
>>> Hello,
>>>
>>> that should be the call lifetime. Are the dialogs terminated after 10
>>> minutes?
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 09.04.18 16:58, tyd wrote:
>>>
>>> Dear all,
>>>
>>> What's the meaning of ims_dialog  default_timeout parameter ?
>>> *Default value is 「43200 (12 hours)」*
>>>
>>> When modparam("ims_dialog", "default_timeout", 600) was set,
>>>

Re: [SR-Users] no corresponding socket found for

2018-04-10 Thread Kjeld Flarup

Listening is configured like this:

#!define LOCALIP 192.168.2.9
#!subst "/LOCALIP/192.168.2.9/g"
listen=127.0.0.1:5069
listen=LOCALIP:5069


Kjeld

2018-04-10 9:43 GMT+02:00 Daniel-Constantin Mierla :

> Hello,
>
> is the instance throwing the error listening only on 127.0.0.1 address?
>
> Cheers,
> Daniel
>
> On 09.04.18 23:54, Kjeld Flarup wrote:
>
> Hi
>
> I have a setup with three kamailio's in the same host but on different
> ports. client ->5069 -> 5070 -> 5071 -> SIP provider
>
> Now I get this error from the 5069 Kamailio when it is routing a 200 Ok to
> the client:
>
> Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
> [forward.c:181]: get_out_socket(): no socket found
> Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
> [forward.c:183]: get_out_socket(): no corresponding socket found for(udp:
> 192.168.2.101:10120)
> Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
> [forward.c:808]: do_forward_reply(): cannot forward reply
>
> By manipulating the database I can skip the 5070 Kamailio, and then it
> works.
>
> I captured these two 200 Ok packets to the 5069 kamailio
>
> *Failing:*
>
> No. Time   SourceDestination
> Protocol Length Info
>4713 21:54:12.814245127.0.0.1 127.0.0.1
> SIP/SDP  2297   Status: 200 OK |
>
> Frame 4713: 2297 bytes on wire (18376 bits), 2297 bytes captured (18376
> bits)
> Linux cooked capture
> Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
> User Datagram Protocol, Src Port: 5070, Dst Port: 5069
> Session Initiation Protocol (200)
> Status-Line: SIP/2.0 200 OK
> Message Header
> Via: SIP/2.0/UDP 127.0.0.1:5069;rport=5069;branch=z9hG4bK6ef1.
> 0c009dcf5b4965c5d1a13d508e0b31c5.0
> Via: SIP/2.0/UDP 192.168.2.101:10120;received=
> 192.168.2.101;rport=10120;branch=z9hG4bKPjIq.uY6jYbHkIqCo03bYLsTzccb7oy9jw
> Record-Route:  yMngm271wI73zx7gmx0CmHdDZWd-w*>
> Record-Route:  039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**>
> Record-Route:  JoLNQGn3057t0SntZ5LNL2QD7Vz12-sjkSTtMxTiB.7Cc-
> 0399LtUqzgSGnCQx0gQ56gLG6g0wn5UILt2NziWIO3ooTDcHdDZ*>
> Record-Route:  7Cc5039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**>
> Record-Route:  7Cc50C9I0goedg9Bzgoedg94OiRbvEynTR7EFm0wFSOZQCOsOiGQs3EIzyUMTi7jnD7qzmWjn-
> UVT3SwTiJx7NLo0Q**>
> Record-Route:  YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;did=8de.7651>
> Record-Route:  YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;did=8de.01b2>
> Record-Route:  YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;vsf=AAABAAAIMDE-;
> did=8de.d821>
> Record-Route:  YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;vsf=AAABAAAIMDE-;
> did=8de.d821>
> From: "Door"  ;tag=
> YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW
> To: 
> ;tag=1865008112
> Call-ID: ou8V0cLHn.P7Oca-pgsnMmrWO43kIQX8
> CSeq: 5778 INVITE
> Contact:  0CQo6gJSngJM7gcHODXPdb7Md5XSvjEqzc**>
> Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,
> UPDATE
> P-AS-Response: 40294149
> Content-Type: application/sdp
> Content-Length: 499
> Message Body
>
> *OK (Without 5070)*
>
> No. Time   SourceDestination
> Protocol Length Info
> 373 21:44:42.955075127.0.0.1 127.0.0.1
> SIP/SDP  2199   Status: 200 OK |
>
> Frame 373: 2199 bytes on wire (17592 bits), 2199 bytes captured (17592
> bits)
> Linux cooked capture
> Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
> User Datagram Protocol, Src Port: 5071, Dst Port: 5069
> Session Initiation Protocol (200)
> Status-Line: SIP/2.0 200 OK
> Message Header
> Via: SIP/2.0/UDP 127.0.0.1:5069;rport=5069;branch=z9hG4bKeea.
> 431611add9dee6ae89135983a85d3021.0
> Via: SIP/2.0/UDP 192.168.2.101:10120;received=
> 192.168.2.101;rport=10120;branch=z9hG4bKPjXjzYAzDU-AJ9ug6mWhSQVI4gwRomuejk
> Record-Route:  yMngm271wI73zx7gmx0CmHdDZWd-w*>
> Record-Route:  039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**>
> Record-Route:  yMn4LSntRr0NzI7NQ574XqnC0M7gQ50NJNL4EgTCQ-7imIQD7Vz12-sjkSTtMxTiB.7Cc-
> 0399LtUqzgSGnCQx0gQ56gLG6g0wn5UILt2NziWIO3ooTDcHdDZ*>
> Record-Route:  7Cc5039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**>
>

Re: [SR-Users] no corresponding socket found for

2018-04-10 Thread Daniel-Constantin Mierla

Hello,

is the instance throwing the error listening only on 127.0.0.1 address?

Cheers,
Daniel


On 09.04.18 23:54, Kjeld Flarup wrote:
>
> Hi
>
> I have a setup with three kamailio's in the same host but on different
> ports. client ->5069 -> 5070 -> 5071 -> SIP provider
>
> Now I get this error from the 5069 Kamailio when it is routing a 200
> Ok to the client:
>
> Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
> [forward.c:181]: get_out_socket(): no socket found
> Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
> [forward.c:183]: get_out_socket(): no corresponding socket found
> for(udp:192.168.2.101:10120)
> Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
> [forward.c:808]: do_forward_reply(): cannot forward reply
>
> By manipulating the database I can skip the 5070 Kamailio, and then it
> works.
>
> I captured these two 200 Ok packets to the 5069 kamailio
>
> *Failing:*
>
> No. Time   Source    Destination  
> Protocol Length Info
>    4713 21:54:12.814245    127.0.0.1 127.0.0.1
> SIP/SDP  2297   Status: 200 OK |
>
> Frame 4713: 2297 bytes on wire (18376 bits), 2297 bytes captured
> (18376 bits)
> Linux cooked capture
> Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
> User Datagram Protocol, Src Port: 5070, Dst Port: 5069
> Session Initiation Protocol (200)
>     Status-Line: SIP/2.0 200 OK
>     Message Header
>     Via: SIP/2.0/UDP
> 127.0.0.1:5069;rport=5069;branch=z9hG4bK6ef1.0c009dcf5b4965c5d1a13d508e0b31c5.0
>     Via: SIP/2.0/UDP
> 192.168.2.101:10120;received=192.168.2.101;rport=10120;branch=z9hG4bKPjIq.uY6jYbHkIqCo03bYLsTzccb7oy9jw
>     Record-Route:
> 
>     Record-Route:
> 
>     Record-Route:
> 
>     Record-Route:
> 
>     Record-Route:
> 
>     Record-Route:
> 
>     Record-Route:
> 
>     Record-Route:
> 
>     Record-Route:
> 
>     From: "Door"
> ;tag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW
>     To: ;tag=1865008112
>     Call-ID: ou8V0cLHn.P7Oca-pgsnMmrWO43kIQX8
>     CSeq: 5778 INVITE
>     Contact:
> 
>     Allow:
> INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE
>     P-AS-Response: 40294149
>     Content-Type: application/sdp
>     Content-Length: 499
>     Message Body
>
> *OK (Without 5070)*
>
> No. Time   Source    Destination  
> Protocol Length Info
>     373 21:44:42.955075    127.0.0.1 127.0.0.1
> SIP/SDP  2199   Status: 200 OK |
>
> Frame 373: 2199 bytes on wire (17592 bits), 2199 bytes captured (17592
> bits)
> Linux cooked capture
> Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
> User Datagram Protocol, Src Port: 5071, Dst Port: 5069
> Session Initiation Protocol (200)
>     Status-Line: SIP/2.0 200 OK
>     Message Header
>     Via: SIP/2.0/UDP
> 127.0.0.1:5069;rport=5069;branch=z9hG4bKeea.431611add9dee6ae89135983a85d3021.0
>     Via: SIP/2.0/UDP
> 192.168.2.101:10120;received=192.168.2.101;rport=10120;branch=z9hG4bKPjXjzYAzDU-AJ9ug6mWhSQVI4gwRomuejk
>     Record-Route:
> 
>     Record-Route:
> 
>     Record-Route:
> 
>     Record-Route:
> 
>     Record-Route:
> 
>     Record-Route:
> 
>     Record-Route:
>

Re: [SR-Users] ims_dialog default_timeout parameter

2018-04-10 Thread tyd

>
> Hello,
>
> On 10.04.18 07:25, tyd wrote:
>
> Hi, Daniel
>
> No, the dialogs were not terminated after 10 minutes if no BYE message was
> sent.
>
>
> Not using ims_dialog, but it may be that it doesn't send bye when the
> dialog lifetime elapses, just destroys the structure it keeps in memory.
> With the other dialog module, there is a parameter to set if you want BYE
> to be sent.
>
> But if Default value(43200) was set,  the S-CSCF will run out of memory
> finally (after 20 calls).
>
> Were all these calls still active?
>
> Hi,
In SIPp, the calls were finishes.
But in Kamailio, the calls seem keep in the memory and run out of memory.
Can any parameter solve this problem?
Is it  a solution  to set "ims_dialog", "default_timeout" to  600 ?

# kamcmd tm.stats
{
current: 69
waiting: 0
total: 991300
total_local: 0
rpl_received: 2183891
rpl_generated: 20232
rpl_sent: 1475856
6xx: 0
5xx: 2704
4xx: 10124
3xx: 0
2xx: 978329
created: 991300
freed: 991231
delayed_free: 0
}
# kamctl stats shmem
shmem:fragments = 1630
shmem:free_size = 4303040
shmem:max_used_size = 536870912
shmem:real_used_size = 532567872
shmem:total_size = 536870912
shmem:used_size = 415668000




>
> Have any relation with this parameter and memory release ?
>
>
> Yes, the structure kept for each call is destroyed after lifetime. But it
> should be also destroyed if the BYE is received.
>
> Cheers,
> Daniel
>
>
> Any impacts if using value 600 at production environment ?
> Thanks.
>
> 2018-04-10 0:27 GMT+08:00 Daniel-Constantin Mierla :
>
>> Hello,
>>
>> that should be the call lifetime. Are the dialogs terminated after 10
>> minutes?
>>
>> Cheers,
>> Daniel
>>
>> On 09.04.18 16:58, tyd wrote:
>>
>> Dear all,
>>
>> What's the meaning of ims_dialog  default_timeout parameter ?
>> *Default value is 「43200 (12 hours)」*
>>
>> When modparam("ims_dialog", "default_timeout", 600) was set,
>> the situation of Kamailio S-CSCF out of memory was solved and is running
>> smoothly.
>>
>> Debian 8 with Kamailio 4.4.7
>>
>>
>>
>>
>>
>> ___
>> 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 - April 16-18, 2018, Berlin - www.asipto.com
>> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>>
>>
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com
> Kamailio World Conference - May 14-16, 2018 - 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] ims_dialog default_timeout parameter

2018-04-10 Thread Daniel-Constantin Mierla

Hello,


On 10.04.18 07:25, tyd wrote:
> Hi, Daniel
>
> No, the dialogs were not terminated after 10 minutes if no BYE message
> was sent.

Not using ims_dialog, but it may be that it doesn't send bye when the
dialog lifetime elapses, just destroys the structure it keeps in memory.
With the other dialog module, there is a parameter to set if you want
BYE to be sent.
> But if Default value(43200) was set,  the S-CSCF will run out of
> memory finally (after 20 calls).
Were all these calls still active?

>
> Have any relation with this parameter and memory release ?

Yes, the structure kept for each call is destroyed after lifetime. But
it should be also destroyed if the BYE is received.

Cheers,
Daniel

> Any impacts if using value 600 at production environment ?
> Thanks.
>
> 2018-04-10 0:27 GMT+08:00 Daniel-Constantin Mierla  >:
>
> Hello,
>
> that should be the call lifetime. Are the dialogs terminated after
> 10 minutes?
>
> Cheers,
> Daniel
>
>
> On 09.04.18 16:58, tyd wrote:
>> Dear all,
>>
>> What's the meaning of ims_dialog  default_timeout parameter ?
>> /Default value is 「43200 (12 hours)」/
>>
>> When modparam("ims_dialog", "default_timeout", 600) was set,
>> the situation of Kamailio S-CSCF out of memory was solved and is
>> running smoothly.
>>
>> Debian 8 with Kamailio 4.4.7
>>
>>
>>
>>
>>
>> ___
>> 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 - April 16-18, 2018, Berlin - www.asipto.com 
> 
> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com 
> 
>
>

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - 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] Issues on fresh install

2018-04-10 Thread Worth Morrison

what does it mean when my siremis login looks like this after an install
that seems to have been successful?
http://pasteall.org/pic/show.php?id=2b72124d5046e2250ad41d14c722c54d

the page is completely non-functional.

Thanks,

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

Re: [SR-Users] ims_dialog default_timeout parameter

Re: [SR-Users] no corresponding socket found for

Re: [SR-Users] rtpengine no voice when working between DTLS-SRTP endpoints

Re: [SR-Users] Kamailio ds_ping_interval Performance

Re: [SR-Users] ims_dialog default_timeout parameter

Re: [SR-Users] no corresponding socket found for

Re: [SR-Users] ims_dialog default_timeout parameter

Re: [SR-Users] no corresponding socket found for

Re: [SR-Users] no corresponding socket found for

Re: [SR-Users] ims_dialog default_timeout parameter

Re: [SR-Users] ims_dialog default_timeout parameter

[SR-Users] Issues on fresh install

12 matches

Site Navigation

Mail list logo

Footer information