[OpenSIPS-Users] Chasing down unreleased memory

[Jock McKechnie]

Greetings OpenSIPS gurus;

I've run into an issue that I'm not making any real headway with on my
own. I have an OpenSIPS 2.4.2 running on CentOS7 that does not appear
to be releasing the bulk of its shared memory when calls die off.
Eventually OpenSIPS runs itself out of shared memory and goes beserk
when it can't reclaim memory for new transactions, or I've also seen
the kernel oomkiller take it down.

The setup is, as mentioned, a 2.4.2 which has a chunk of perl living
on its back that handles some API directed call decisions. Because of
the inevitable delay in the API lookups I am running a large number of
threads (100) to ensure that I don't start dropping packets under high
levels of load (50 CPS+ - until I bumped children counts up I was
seeing packets being ignored which got the End User very excitable). I
appreciate having lots of children amplifies memory usage but my
belief is during regular load on our side (~6000 calls at ~30 - 40CPS)
I should have a full day's runtime easily w/o running into problems.
The issue is that because the memory is not released overnight it
starts the next day with half its shared memory gone, and then things
go to pot the next day when it runs through all its remaining shared
memory.

I have it configured for a very large (I think) amount of memory to
attempt to compensate short-term - 2048MB shared memory, 128MB package
memory. This is not a well thought-out number, just me throwing RAM at
the problem. (For reference this is on a VM running with 4 cores and
4096MB of RAM)

I have graphed the memory stats out of the FIFO, after enabling
memstats and DBG_MALLOC/etc. The graphs can be found here:
https://imgur.com/a/oapKYJW

You'll see that the first graph, the main shmem:, shows the usage gets
tied up and remains after calls die off (these examples run for 20
minutes after the calls stopped - but I can leave it overnight and the
shmem: usage won't drop). This being said, the other graphed modules
show that it releases memory correctly after calls quit like they
should. None of the other modules graphed (eg, _all_ of the modules I
was using in OpenSIPS) showed no significant usage and I've omitted
them.

Interesting that the 'perl' module shows no stats ever which makes me
wonder if the stats on this module works. I am not storing anything
inside perl, besides lots of local session variables, and all channel
variables are pushed back into OpenSIPS AVPs, but I assume there must
be some memory overhead, although it may not significantly change.

When I shut OpenSIPS down I get child dumps like the following: (I've
included only one for brevity, but they're all much of a muchness)
https://pastebin.com/KG2qxxBa

If I'm reading this right (and there's a strong possibility I'm
misunderstanding what I'm looking at) the memory is tied up in io_wait
and the parser. I'm not sure what this signifies, however.

So I guess what I'm asking is:
Am I understanding what I'm looking at correctly and that OpenSIPS is
not releasing its shared memory which causes it to run out of memory
quicker the following day? (Which lines up with the symptoms of
shorter runtimes before failure)

Based on the dumps where should I look for the source of this issue?

Finally, and unrelated to the above, I attempted to mail the official
OpenSIPS peeps to talk about paid support but none of the 'contact us'
submits appear to work - when I click on the submit button it changes
shade but does not appear to act. Certainly I never received any
response. If there was a direct eMail address I could send to that
would be preferable.

As always, my thanks for your time.

 - Jock

PS -
List of modules I'm using in this config:loadmodule "signaling.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "textops.so"
loadmodule "uri.so"
loadmodule "mi_fifo.so"
loadmodule "siptrace.so"
loadmodule "sipmsgops.so"
loadmodule "dialog.so"
loadmodule "uac_auth.so"
loadmodule "uac.so"
loadmodule "perl.so"
loadmodule "acc.so"
loadmodule "proto_hep.so"
loadmodule "proto_udp.so"
loadmodule "compression.so"

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Doubts on call-center scenario

[Daniel Zanutti]

Hi Bogdan

I'm triggering the script via MI. The idea is to send some parameter with
the MI parameters and use this as a variable on localroute.

For example, a dialer place call to B destination, after answer, place call
to A destination, then bridge.

On B side, i need to store on DB the gateway_id that will process the call.
On A side, I'll call the Queue number, but I need to send and store the
campaign ID. These 2 values must be stored on CDR.

I didn't find a way to send, for example, the gateway_id to the opensips
script when using B2B.

Thanks

On Thu, Sep 20, 2018 at 12:48 PM Bogdan-Andrei Iancu 
wrote:

> Hi Daniel,
>
> Could you detail a bit on the flow of this customer related value ? where
> does is originate (when triggering the b2b script via MI?) and where do you
> want to get it ?
>
> Best regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>   http://opensips.org/training/OpenSIPS_Bootcamp_2018/
>
> On 09/12/2018 12:32 AM, Daniel Zanutti wrote:
>
> Hi everyone,
>
> I'm using opensips to originate a call to 2 destinations then bridge then,
> using B2B scenario.
>
> How to send some custom parameters to help accounting?
> I need to identify that this specific call, is related to some customer.
> Didn't find in docs a proper way to do it, so my idea is to set r-uri with
> some kind of csv data then fix it before it's sent out on local_route. But
> I'm unsure this is a good idea.
>
> Is there a proper way to send custom parameter to be handled on
> local_route?
>
> Thanks
>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Crash in logging

[Dan Pascu]

On 20 Sep 2018, at 19:08, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> Please report this on the GitHub tracker ; in addition - is the crash 
> reproducible , have you identified the faulty xlog() in your script ? is all 
> the time the same ?

It happened multiple times, but I cannot reproduce it at will. The crashes are 
random. What seems to be common in all cases is that the frm variable in frame 
12 looks like corrupted memory. The value there seems to always be different, 
but always garbage.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 09/20/2018 06:59 PM, Dan Pascu wrote:
>> Here is another crash that happened multiple times:
>> 
>> Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid 
>> -m 512'.
>> Program terminated with signal SIGABRT, Aborted.
>> #0  0xb770ccf9 in __kernel_vsyscall ()
>> (gdb) bt
>> #0  0xb770ccf9 in __kernel_vsyscall ()
>> #1  0xb7546dd0 in __libc_signal_restore_set (set=0xbfb81eb0) at 
>> ../sysdeps/unix/sysv/linux/nptl-signals.h:79
>> #2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
>> #3  0xb7548297 in __GI_abort () at abort.c:89
>> #4  0xb758238f in __libc_message (do_abort=, fmt=> out>) at ../sysdeps/posix/libc_fatal.c:175
>> #5  0xb7588fc7 in malloc_printerr (action=, str=0xb7678cc6 
>> "corrupted size vs. prev_size", ptr=, ar_ptr=0xb76ce780 
>> ) at malloc.c:5049
>> #6  0xb758b4d5 in _int_malloc (av=av@entry=0xb76ce780 , 
>> bytes=bytes@entry=360) at malloc.c:3765
>> #7  0xb758cbf5 in __GI___libc_malloc (bytes=360) at malloc.c:2928
>> #8  0xb7580d8b in __GI___open_memstream (bufloc=0xbfb823ac, 
>> sizeloc=0xbfb823b0) at memstream.c:76
>> #9  0xb75fdf35 in __GI___vsyslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s", 
>> ap=0xbfb8245c "\035") at ../misc/syslog.c:167
>> #10 0xb75fe449 in __syslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s") at 
>> ../misc/syslog.c:129
>> #11 0x0052bd6b in syslog (__fmt=0x65edf4 "%.*s", __pri=) at 
>> /usr/include/i386-linux-gnu/bits/syslog.h:31
>> #12 xlog_2 (msg=0x190d480, lev=0x18dba80 "", frm=0x18dbac0 " 
>> \372\177\001\035") at xlog.c:230
>> #13 0x004efc5a in do_action (a=0x17ffaa8, msg=0x190d480) at action.c:1638
>> #14 0x004f300a in run_action_list (a=0x17ffaa8, msg=0x190d480) at 
>> action.c:172
>> #15 0x004f2041 in do_action (a=0x1800678, msg=0x190d480) at action.c:1130
>> #16 0x004f300a in run_action_list (a=0x17f9ad0, msg=0x190d480) at 
>> action.c:172
>> #17 0x004f330a in run_actions (msg=0x190d480, a=0x17f9ad0) at action.c:137
>> #18 run_top_route (a=0x17f9ad0, msg=0x190d480) at action.c:214
>> #19 0x004f9a33 in receive_msg (buf=, len=, 
>> rcv_info=, existing_context=, flags=> out>) at receive.c:209
>> #20 0x00642878 in tcp_handle_req (_max_msg_chunks=, 
>> con=0x97d793ec, req=0x77bea0 ) at 
>> net/proto_tcp/tcp_common.h:411
>> #21 tcp_read_req (con=0x97d793ec, bytes_read=0xbfb82f18) at 
>> net/proto_tcp/proto_tcp.c:1179
>> #22 0x00622a8e in handle_io (fm=, idx=idx@entry=0, 
>> event_type=event_type@entry=1) at net/net_tcp_proc.c:241
>> #23 0x006250d5 in io_wait_loop_epoll (h=, t=, 
>> repeat=) at net/../io_wait_loop.h:280
>> #24 tcp_worker_proc_loop () at net/net_tcp_proc.c:386
>> #25 0x00630993 in tcp_start_processes (chd_rank=0x758980 , 
>> startup_done=0x0) at net/net_tcp.c:1887
>> #26 0x004d642c in main_loop () at main.c:761
>> #27 main (argc=, argv=) at main.c:1407
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 


--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Delayed timer executions

[Dan Pascu]

On 20 Sep 2018, at 19:06, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> Copying from my previous reply to Pasan:
> 
> 
> "If there is no load (worker processes are idle, no busy with anything else), 
> the reported delay may be generated only by the interprocess communication 
> (passing the job from the triggering process to the executing process via 
> internal pipes).
> 
> What are the values you typically observe ? maybe the warning is jst about a 
> slow context switching on your server (btw, how many cores ?)."

While I would agree with you for these messages:

./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 4 us delay in execution
./opensips[21850]: WARNING:core:handle_timer_job: timer job 
 has a 5 us delay in execution

that indicate a 40-50ms delay, I do not think that you can blame context 
switching for these messages:

Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: 
timer task  already scheduled 29850 ms ago (now 1238480 ms), delaying 
execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29850 ms ago (now 1238580 ms), 
delaying execution

If I read them correctly they say that the timer was already scheduled 30 
seconds ago and the timer already has a lifetime of 1238 seconds - almost 
21minutes!!! - and still hasn't fired yet.

Plus the system I use is a 4 core real machine, so how bad can the context 
switching be that I see my log flooded with these messages (the later type of 
messages were logged every 100ms for 30 seconds - which makes them like 300 log 
messages whenever this happens)?

Re-read my second message on the matter, because those do not look like context 
switching.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 09/20/2018 06:55 PM, Dan Pascu wrote:
>> On 20 Sep 2018, at 18:19, Pasan Meemaduma via Users wrote:
>> 
>>> Hi Dan,
>>> 
>>> I'm experiencing same on 2.3.5 as per my initial email. still couldn't find 
>>> out the exact reason. btw are you using a virtualise environment ?
>> No
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 


--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Segmentation fault in master

[Dan Pascu]

On 20 Sep 2018, at 19:04, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> Please report this on the GitHub tracker ; in addition - is the crash 
> reproducible ?

It happened multiple times, but I do not have a way to reproduce it at will.

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  http://www.opensips-solutions.com
> OpenSIPS Bootcamp 2018
>  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
> 
> On 09/20/2018 05:15 PM, Dan Pascu wrote:
>> I got this crash (memory seems to be corrupted in src->h_addr_list[0]):
>> 
>> Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid 
>> -m 512'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  __memcpy_sse2_unaligned () at 
>> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
>> 667  ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file or 
>> directory.
>> (gdb) bt
>> #0  __memcpy_sse2_unaligned () at 
>> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
>> #1  0x004faf84 in memcpy (__len=, __src=, 
>> __dest=0x97e04ad4) at /usr/include/i386-linux-gnu/bits/string3.h:53
>> #2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
>> #3  0x96bd108e in shm_clone_proxy (move_dn=, sp=> out>) at ../../resolve.h:391
>> #4  add_uac (t=t@entry=0x97dfc584, request=request@entry=0x96c07240 
>> , uri=uri@entry=0xbfae0790, next_hop=, 
>> bflags=, path=, proxy=) at 
>> t_fwd.c:437
>> #5  0x96bd442a in t_forward_nonack (t=, p_msg=> out>, proxy=, reset_bcounter=, 
>> locked=) at t_fwd.c:757
>> #6  0x96b7d5d4 in do_dns_failover (t=t@entry=0x97dfc584) at t_reply.c:702
>> #7  0x96b7fa44 in t_should_relay_response (Trans=Trans@entry=0x97dfc584, 
>> new_code=new_code@entry=408, branch=branch@entry=0, should_store=0xbfae0a00, 
>> should_relay=0xbfae09fc, cancel_bitmap=0xbfae0ad8, reply=0x) at 
>> t_reply.c:962
>> #8  0x96b81b84 in relay_reply (t=0x97dfc584, p_msg=0x, branch=0, 
>> msg_status=408, cancel_bitmap=0xbfae0ad8) at t_reply.c:1206
>> #9  0x96bcdc0c in fake_reply (code=408, branch=, 
>> t=0x97dfc584) at timer.c:260
>> #10 final_response_handler (fr_tl=) at timer.c:399
>> #11 timer_routine (ticks=1350, set=0x0) at timer.c:1074
>> #12 0x005422e4 in handle_timer_job () at timer.c:738
>> #13 0x0061e835 in handle_io (idx=, event_type=> out>, fm=) at net/net_udp.c:265
>> #14 io_wait_loop_epoll (h=, t=, 
>> repeat=) at net/../io_wait_loop.h:284
>> #15 udp_start_processes (chd_rank=0x759980 , startup_done=0x0) at 
>> net/net_udp.c:389
>> #16 0x004d7418 in main_loop () at main.c:755
>> #17 main (argc=, argv=) at main.c:1407
>> (gdb) frame 2
>> #2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
>> 75   proxy.c: No such file or directory.
>> (gdb) print *src
>> $1 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 2, h_length = 4, 
>> h_addr_list = 0x97df1dd8}
>> (gdb) print *dst
>> $2 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 0, h_length = 0, 
>> h_addr_list = 0x97e04abc}
>> (gdb) print src->h_addr_list[0]
>> $4 = 0x22e1f08 
>> (gdb) print src->h_addr_list[1]
>> $5 = 0x97df1dec "Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
>> (gdb) print src->h_addr_list[2]
>> $6 = 0x97df1de8 
>> "Q\027\344\226Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
>> (gdb) print src->h_addr_list[3]
>> $7 = 0x0
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 


--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] timer execution delay

[Pasan Meemaduma via Users]

 Hi Bogdan,

Nice to here from you :) Thank for clarifying about the warning. My delay times 
are only vary between 4 us - 5 us. I got 6 vCPUs allocated to my kvm 
guest , host machine has 16 cores in total. I wondered if these are related to 
guest CPU stealing as I get 0.02% of max cpu steal value according our 
monitoring graphs.

Host CPUs
lscpu
Architecture:  x86_64
CPU op-mode(s):    32-bit, 64-bit
Byte Order:    Little Endian
CPU(s):    64
On-line CPU(s) list:   0-63
Thread(s) per core:    2
Core(s) per socket:    16
Socket(s): 2



On Thursday, 20 September 2018, 9:27:24 PM GMT+5:30, Bogdan-Andrei Iancu 
 wrote:  
 
  Hi Pasan,
 
 That warning (harmless in 99% of the cases) reports the delays between (a) 
triggering a timer job in timer processes and (b) executing that timer job in a 
worker process.
 
 If there is no load (worker processes are idle, no busy with anything else), 
the reported delay may be generated only by the interprocess communication 
(passing the job from the triggering process to the executing process via 
internal pipes).
 
 What are the values you typically observe ? maybe the warning is jst about a 
slow context switching on your server (btw, how many cores ?).
 
 Regards, 
 Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
 On 09/14/2018 06:16 AM, Pasan Meemaduma via Users wrote:
  
  Hi Guys, 
  I'm seeing the following warnings on my opensips 2.3.5 boxes even when they 
are idle. (just pinging about 8 asterisk gateways in drouting module for health 
check) 
  Sep 14 06:38:23  /usr/sbin/opensips[6373]: WARNING:core:handle_timer_job: 
timer job  has a 4 us delay in execution
 Sep 14 08:31:53  /usr/sbin/opensips[6362]: WARNING:core:handle_timer_job: 
utimer job  has a 4 us delay in execution
 Sep 14 12:15:38  /usr/sbin/opensips[6365]: WARNING:core:handle_timer_job: 
timer job  has a 4 us delay in execution
 Sep 14 12:15:38  /usr/sbin/opensips[6363]: WARNING:core:handle_timer_job: 
timer job  has a 4 us delay in execution
  
  The servers doesn't process anything most of the time. I'm wondering whats 
causing these warnings. I tired script_trace and enable debug level 5 and 
nothing explains why it complains like this. It just pops out in the log 
without any other related log line. 
  /root>> opensips -V
 version: opensips 2.3.5 (x86_64/linux)
 flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, 
FAST_LOCK-ADAPTIVE_WAIT
 ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
MAX_URI_SIZE 1024, BUF_SIZE 65535
 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
 main.c compiled on  with gcc 6.3.0
 
  Its a KVM guest and has 6 CPUs allocated. cat /proc/cpuinfo 
 processor   : 0
 vendor_id   : AuthenticAMD
 cpu family  : 23
 model   : 1
 model name  : AMD EPYC Processor (with IBPB)
 stepping    : 2
 microcode   : 0x165
 cpu MHz : 2095.956
 cache size  : 512 KB
 physical id : 0
 siblings    : 6
 core id : 64
 cpu cores   : 1
 apicid  : 0
 initial apicid  : 0
 fpu : yes
 fpu_exception   : yes
 cpuid level : 13
 wp  : yes
 bogomips    : 4191.91
 TLB size    : 1024 4K pages
 clflush size    : 64
 cache_alignment : 64
 address sizes   : 40 bits physical, 48 bits virtual
 power management:
 
  Would be nice to know how I could hunt down this issue.  
  
  Thanks
  
 
  
 ___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 
   ___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Delayed timer executions

[Bogdan-Andrei Iancu]

Hi Dan,

Copying from my previous reply to Pasan:


"If there is no load (worker processes are idle, no busy with anything 
else), the reported delay may be generated only by the interprocess 
communication (passing the job from the triggering process to the 
executing process via internal pipes).


What are the values you typically observe ? maybe the warning is jst 
about a slow context switching on your server (btw, how many cores ?)."


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
  http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/20/2018 06:55 PM, Dan Pascu wrote:

On 20 Sep 2018, at 18:19, Pasan Meemaduma via Users wrote:


Hi Dan,

I'm experiencing same on 2.3.5 as per my initial email. still couldn't find out 
the exact reason. btw are you using a virtualise environment ?

No

--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Crash in logging

[Bogdan-Andrei Iancu]

Hi Dan,

Please report this on the GitHub tracker ; in addition - is the crash 
reproducible , have you identified the faulty xlog() in your script ? is 
all the time the same ?


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
  http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/20/2018 06:59 PM, Dan Pascu wrote:

Here is another crash that happened multiple times:

Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 
512'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb770ccf9 in __kernel_vsyscall ()
(gdb) bt
#0  0xb770ccf9 in __kernel_vsyscall ()
#1  0xb7546dd0 in __libc_signal_restore_set (set=0xbfb81eb0) at 
../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xb7548297 in __GI_abort () at abort.c:89
#4  0xb758238f in __libc_message (do_abort=, fmt=) at ../sysdeps/posix/libc_fatal.c:175
#5  0xb7588fc7 in malloc_printerr (action=, str=0xb7678cc6 "corrupted size vs. 
prev_size", ptr=, ar_ptr=0xb76ce780 ) at malloc.c:5049
#6  0xb758b4d5 in _int_malloc (av=av@entry=0xb76ce780 , 
bytes=bytes@entry=360) at malloc.c:3765
#7  0xb758cbf5 in __GI___libc_malloc (bytes=360) at malloc.c:2928
#8  0xb7580d8b in __GI___open_memstream (bufloc=0xbfb823ac, sizeloc=0xbfb823b0) 
at memstream.c:76
#9  0xb75fdf35 in __GI___vsyslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s", ap=0xbfb8245c 
"\035") at ../misc/syslog.c:167
#10 0xb75fe449 in __syslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s") at 
../misc/syslog.c:129
#11 0x0052bd6b in syslog (__fmt=0x65edf4 "%.*s", __pri=) at 
/usr/include/i386-linux-gnu/bits/syslog.h:31
#12 xlog_2 (msg=0x190d480, lev=0x18dba80 "", frm=0x18dbac0 " \372\177\001\035") 
at xlog.c:230
#13 0x004efc5a in do_action (a=0x17ffaa8, msg=0x190d480) at action.c:1638
#14 0x004f300a in run_action_list (a=0x17ffaa8, msg=0x190d480) at action.c:172
#15 0x004f2041 in do_action (a=0x1800678, msg=0x190d480) at action.c:1130
#16 0x004f300a in run_action_list (a=0x17f9ad0, msg=0x190d480) at action.c:172
#17 0x004f330a in run_actions (msg=0x190d480, a=0x17f9ad0) at action.c:137
#18 run_top_route (a=0x17f9ad0, msg=0x190d480) at action.c:214
#19 0x004f9a33 in receive_msg (buf=, len=, rcv_info=, existing_context=, flags=) at receive.c:209
#20 0x00642878 in tcp_handle_req (_max_msg_chunks=, con=0x97d793ec, 
req=0x77bea0 ) at net/proto_tcp/tcp_common.h:411
#21 tcp_read_req (con=0x97d793ec, bytes_read=0xbfb82f18) at 
net/proto_tcp/proto_tcp.c:1179
#22 0x00622a8e in handle_io (fm=, idx=idx@entry=0, 
event_type=event_type@entry=1) at net/net_tcp_proc.c:241
#23 0x006250d5 in io_wait_loop_epoll (h=, t=, 
repeat=) at net/../io_wait_loop.h:280
#24 tcp_worker_proc_loop () at net/net_tcp_proc.c:386
#25 0x00630993 in tcp_start_processes (chd_rank=0x758980 , 
startup_done=0x0) at net/net_tcp.c:1887
#26 0x004d642c in main_loop () at main.c:761
#27 main (argc=, argv=) at main.c:1407

--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Segmentation fault in master

[Bogdan-Andrei Iancu]

Hi Dan,

Please report this on the GitHub tracker ; in addition - is the crash 
reproducible ?


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
  http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/20/2018 05:15 PM, Dan Pascu wrote:

I got this crash (memory seems to be corrupted in src->h_addr_list[0]):

Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 
512'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __memcpy_sse2_unaligned () at 
../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
667 ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file or 
directory.
(gdb) bt
#0  __memcpy_sse2_unaligned () at 
../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
#1  0x004faf84 in memcpy (__len=, __src=, 
__dest=0x97e04ad4) at /usr/include/i386-linux-gnu/bits/string3.h:53
#2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
#3  0x96bd108e in shm_clone_proxy (move_dn=, sp=) 
at ../../resolve.h:391
#4  add_uac (t=t@entry=0x97dfc584, request=request@entry=0x96c07240 , 
uri=uri@entry=0xbfae0790, next_hop=, bflags=, path=, proxy=) at t_fwd.c:437
#5  0x96bd442a in t_forward_nonack (t=, p_msg=, proxy=, reset_bcounter=, locked=) at t_fwd.c:757
#6  0x96b7d5d4 in do_dns_failover (t=t@entry=0x97dfc584) at t_reply.c:702
#7  0x96b7fa44 in t_should_relay_response (Trans=Trans@entry=0x97dfc584, 
new_code=new_code@entry=408, branch=branch@entry=0, should_store=0xbfae0a00, 
should_relay=0xbfae09fc, cancel_bitmap=0xbfae0ad8, reply=0x) at 
t_reply.c:962
#8  0x96b81b84 in relay_reply (t=0x97dfc584, p_msg=0x, branch=0, 
msg_status=408, cancel_bitmap=0xbfae0ad8) at t_reply.c:1206
#9  0x96bcdc0c in fake_reply (code=408, branch=, t=0x97dfc584) 
at timer.c:260
#10 final_response_handler (fr_tl=) at timer.c:399
#11 timer_routine (ticks=1350, set=0x0) at timer.c:1074
#12 0x005422e4 in handle_timer_job () at timer.c:738
#13 0x0061e835 in handle_io (idx=, event_type=, 
fm=) at net/net_udp.c:265
#14 io_wait_loop_epoll (h=, t=, repeat=) at net/../io_wait_loop.h:284
#15 udp_start_processes (chd_rank=0x759980 , startup_done=0x0) at 
net/net_udp.c:389
#16 0x004d7418 in main_loop () at main.c:755
#17 main (argc=, argv=) at main.c:1407
(gdb) frame 2
#2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
75  proxy.c: No such file or directory.
(gdb) print *src
$1 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 2, h_length = 4, h_addr_list 
= 0x97df1dd8}
(gdb) print *dst
$2 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 0, h_length = 0, h_addr_list 
= 0x97e04abc}
(gdb) print src->h_addr_list[0]
$4 = 0x22e1f08 
(gdb) print src->h_addr_list[1]
$5 = 0x97df1dec "Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
(gdb) print src->h_addr_list[2]
$6 = 0x97df1de8 
"Q\027\344\226Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
(gdb) print src->h_addr_list[3]
$7 = 0x0

--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Crash in logging

[Dan Pascu]

Here is another crash that happened multiple times:

Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 
512'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb770ccf9 in __kernel_vsyscall ()
(gdb) bt
#0  0xb770ccf9 in __kernel_vsyscall ()
#1  0xb7546dd0 in __libc_signal_restore_set (set=0xbfb81eb0) at 
../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xb7548297 in __GI_abort () at abort.c:89
#4  0xb758238f in __libc_message (do_abort=, fmt=) at ../sysdeps/posix/libc_fatal.c:175
#5  0xb7588fc7 in malloc_printerr (action=, str=0xb7678cc6 
"corrupted size vs. prev_size", ptr=, ar_ptr=0xb76ce780 
) at malloc.c:5049
#6  0xb758b4d5 in _int_malloc (av=av@entry=0xb76ce780 , 
bytes=bytes@entry=360) at malloc.c:3765
#7  0xb758cbf5 in __GI___libc_malloc (bytes=360) at malloc.c:2928
#8  0xb7580d8b in __GI___open_memstream (bufloc=0xbfb823ac, sizeloc=0xbfb823b0) 
at memstream.c:76
#9  0xb75fdf35 in __GI___vsyslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s", 
ap=0xbfb8245c "\035") at ../misc/syslog.c:167
#10 0xb75fe449 in __syslog_chk (pri=134, flag=1, fmt=0x65edf4 "%.*s") at 
../misc/syslog.c:129
#11 0x0052bd6b in syslog (__fmt=0x65edf4 "%.*s", __pri=) at 
/usr/include/i386-linux-gnu/bits/syslog.h:31
#12 xlog_2 (msg=0x190d480, lev=0x18dba80 "", frm=0x18dbac0 " \372\177\001\035") 
at xlog.c:230
#13 0x004efc5a in do_action (a=0x17ffaa8, msg=0x190d480) at action.c:1638
#14 0x004f300a in run_action_list (a=0x17ffaa8, msg=0x190d480) at action.c:172
#15 0x004f2041 in do_action (a=0x1800678, msg=0x190d480) at action.c:1130
#16 0x004f300a in run_action_list (a=0x17f9ad0, msg=0x190d480) at action.c:172
#17 0x004f330a in run_actions (msg=0x190d480, a=0x17f9ad0) at action.c:137
#18 run_top_route (a=0x17f9ad0, msg=0x190d480) at action.c:214
#19 0x004f9a33 in receive_msg (buf=, len=, 
rcv_info=, existing_context=, flags=) at receive.c:209
#20 0x00642878 in tcp_handle_req (_max_msg_chunks=, 
con=0x97d793ec, req=0x77bea0 ) at 
net/proto_tcp/tcp_common.h:411
#21 tcp_read_req (con=0x97d793ec, bytes_read=0xbfb82f18) at 
net/proto_tcp/proto_tcp.c:1179
#22 0x00622a8e in handle_io (fm=, idx=idx@entry=0, 
event_type=event_type@entry=1) at net/net_tcp_proc.c:241
#23 0x006250d5 in io_wait_loop_epoll (h=, t=, 
repeat=) at net/../io_wait_loop.h:280
#24 tcp_worker_proc_loop () at net/net_tcp_proc.c:386
#25 0x00630993 in tcp_start_processes (chd_rank=0x758980 , 
startup_done=0x0) at net/net_tcp.c:1887
#26 0x004d642c in main_loop () at main.c:761
#27 main (argc=, argv=) at main.c:1407

--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Accounting BYE response

[Ben Newlin]

Bogdan,

This is a good point and I did consider that. However, this only makes sense in 
the case where there is a successful response prior to the error response. As I 
noted I have seen this occur when both parties reply to the BYE with a 481 
response. If the Dialog and ACC modules were triggering on the first BYE reply 
received, then my flag should still be getting set in this case as the first 
reply is guaranteed to be a failure.

Is it possible the dialog termination and CDR generation are being triggered 
prior to the failure_route callback? If so, are they also triggered prior to a 
reply_route callback? Would it make sense to delay the dialog termination until 
after failure_route processing to allow the script to make final adjustments to 
the CDR such as this?

Ben Newlin

From: Bogdan-Andrei Iancu 
Date: Thursday, September 20, 2018 at 11:42 AM
To: OpenSIPS users mailling list , Ben Newlin 

Subject: Re: [OpenSIPS-Users] Accounting BYE response

Hi Ben,

The issue is a bit more complex. When generating the BYE requests, the dialog 
module triggers the event of call terminated when it gets back the first final 
reply (to any of the BYEs). And ACC module generates the CDR when the dialog is 
terminated.

So, the second BYE (which probably ends with timeout) ends in failure route 
(and set the acc extra) *after* the call was terminated and the CDR generated.

Regards,


Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  http://www.opensips-solutions.com

OpenSIPS Bootcamp 2018

  http://opensips.org/training/OpenSIPS_Bootcamp_2018/
On 09/08/2018 01:00 AM, Ben Newlin wrote:
David,

I agree that there are better ways to do billing, but I must work within the 
constraints of the larger system of which I am only a part.

We do use some other techniques to detect “stuck” calls, including the (fairly) 
new Re-Invite pinging mechanism of the dialog module. We do not process the 
audio, so silence detection is not possible.

It is a very small number of calls that are affected by this, hopefully none 
now that we have the pinging in place, but I am still interested in the answer 
to the question. It seems to me there could be other use cases for modifying 
the CDR based on the response to a BYE, whether generated from OpenSIPS or not.

Ben Newlin

From: Users 
 on 
behalf of David Villasmil 

Reply-To: OpenSIPS users mailling list 

Date: Friday, September 7, 2018 at 5:53 PM
To: OpenSIPS users mailling list 

Subject: Re: [OpenSIPS-Users] Accounting BYE response


I think you should take care of this on your gateway. For example, using 
freeswitch or asterisk, you can check for rtps, and when the other end stops 
sending rtps for 30 seconds (configurable) it will tear down the call properly.

Unless you're using a rtp-proxy with opensips which can do this (most can), 
that's the way to do this. Anything else is just duct-taping.

My opinion after 20 years on voip.

Hope that helps.

David

On Fri, Sep 7, 2018, 21:43 Ben Newlin 
mailto:ben.new...@genesys.com>> wrote:
Hi,

I am having an issue trying to add values to accounting based on the response 
to the BYE request.

We use the dialog timeout mechanism to terminate long calls in our system. In 
some cases, these are “valid” calls that remained connected for too long due to 
some error elsewhere in the application. But sometimes one or both ends of the 
call believe they have disconnected, but we did not receive or process the 
disconnect, due to a malformed BYE or a network disruption. In these cases, 
when the Dialog timeout is reached and OpenSIPS generates a BYE to both 
parties, they will respond with a 481.

What I want is to set a CDR flag on receipt of that 481 to indicate that there 
was an error and the calculated call time may not be correct. But it seems that 
any accounting flags set after the BYE is sent are not honored. Is there any 
way to accomplish this?

This is my attempt:

failure_route[local_failure]
{
  $acc_extra(disconnect_error) = "true";
}

local_route
{
  t_on_failure("local_failure");
}

Ben Newlin
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




___

Users mailing list

Users@lists.opensips.org

http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] timer execution delay

[Bogdan-Andrei Iancu]

Hi Pasan,

That warning (harmless in 99% of the cases) reports the delays between 
(a) triggering a timer job in timer processes and (b) executing that 
timer job in a worker process.


If there is no load (worker processes are idle, no busy with anything 
else), the reported delay may be generated only by the interprocess 
communication (passing the job from the triggering process to the 
executing process via internal pipes).


What are the values you typically observe ? maybe the warning is jst 
about a slow context switching on your server (btw, how many cores ?).


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
  http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/14/2018 06:16 AM, Pasan Meemaduma via Users wrote:

Hi Guys,

I'm seeing the following warnings on my opensips 2.3.5 boxes even when 
they are idle. (just pinging about 8 asterisk gateways in drouting 
module for health check)


Sep 14 06:38:23 /usr/sbin/opensips[6373]: 
WARNING:core:handle_timer_job: timer job  has a 4 
us delay in execution
Sep 14 08:31:53  /usr/sbin/opensips[6362]: 
WARNING:core:handle_timer_job: utimer job  has a 4 us 
delay in execution
Sep 14 12:15:38  /usr/sbin/opensips[6365]: 
WARNING:core:handle_timer_job: timer job  has a 4 us 
delay in execution
Sep 14 12:15:38  /usr/sbin/opensips[6363]: 
WARNING:core:handle_timer_job: timer job  has a 4 us 
delay in execution


The servers doesn't process anything most of the time. I'm wondering 
whats causing these warnings. I tired script_trace and enable debug 
level 5 and nothing explains why it complains like this. It just pops 
out in the log without any other related log line.


/root>> opensips -V
version: opensips 2.3.5 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, 
F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 
MAX_URI_SIZE 1024, BUF_SIZE 65535

poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
main.c compiled on  with gcc 6.3.0

Its a KVM guest and has 6 CPUs allocated.
cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 23
model   : 1
model name  : AMD EPYC Processor (with IBPB)
stepping: 2
microcode   : 0x165
cpu MHz : 2095.956
cache size  : 512 KB
physical id : 0
siblings: 6
core id : 64
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
bogomips: 4191.91
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

Would be nice to know how I could hunt down this issue.


Thanks



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Delayed timer executions

[Dan Pascu]

On 20 Sep 2018, at 18:19, Pasan Meemaduma via Users wrote:

> Hi Dan,
> 
> I'm experiencing same on 2.3.5 as per my initial email. still couldn't find 
> out the exact reason. btw are you using a virtualise environment ?

No

--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Doubts on call-center scenario

[Bogdan-Andrei Iancu]

Hi Daniel,

Could you detail a bit on the flow of this customer related value ? 
where does is originate (when triggering the b2b script via MI?) and 
where do you want to get it ?


Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
  http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/12/2018 12:32 AM, Daniel Zanutti wrote:

Hi everyone,

I'm using opensips to originate a call to 2 destinations then bridge 
then, using B2B scenario.


How to send some custom parameters to help accounting?
I need to identify that this specific call, is related to some 
customer. Didn't find in docs a proper way to do it, so my idea is to 
set r-uri with some kind of csv data then fix it before it's sent out 
on local_route. But I'm unsure this is a good idea.


Is there a proper way to send custom parameter to be handled on 
local_route?


Thanks



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Remove "Route" header in initial (out dialog) INVITE request before forwarding

[Bogdan-Andrei Iancu]

Hi Ravi,

why do you say the remove_hf() doesn't work ? do you still see the 
incoming Route hdr in the outbound message ??


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
  http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/10/2018 08:14 AM, Ravi wrote:


Hello,

I am using opensips (2.3)as Proxy service and my requirement is to  
remove “Route” header in initial (out dialog) INVITE request before 
forwarding to next Hop. This is because I don’t want to follow the 
route set from End Point as I have my internal route.


I tried option “remove_hf("Route")”  from configuration but  still 
Route header is not being removed when forwarding to next Hop.


I cannot use “loose_route” which only remove Route header when matched 
 self  but my requirement is to remove all Route header (if present 
multiple). Please suggest on  how can I do that.


Regards,

V Ravi Kumar



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Accounting BYE response

[Bogdan-Andrei Iancu]

Hi Ben,

The issue is a bit more complex. When generating the BYE requests, the 
dialog module triggers the event of call terminated when it gets back 
the first final reply (to any of the BYEs). And ACC module generates the 
CDR when the dialog is terminated.


So, the second BYE (which probably ends with timeout) ends in failure 
route (and set the acc extra) *after* the call was terminated and the 
CDR generated.


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
  http://opensips.org/training/OpenSIPS_Bootcamp_2018/

On 09/08/2018 01:00 AM, Ben Newlin wrote:


David,

I agree that there are better ways to do billing, but I must work 
within the constraints of the larger system of which I am only a part.


We do use some other techniques to detect “stuck” calls, including the 
(fairly) new Re-Invite pinging mechanism of the dialog module. We do 
not process the audio, so silence detection is not possible.


It is a very small number of calls that are affected by this, 
hopefully none now that we have the pinging in place, but I am still 
interested in the answer to the question. It seems to me there could 
be other use cases for modifying the CDR based on the response to a 
BYE, whether generated from OpenSIPS or not.


Ben Newlin

*From: *Users  on behalf of David 
Villasmil 

*Reply-To: *OpenSIPS users mailling list 
*Date: *Friday, September 7, 2018 at 5:53 PM
*To: *OpenSIPS users mailling list 
*Subject: *Re: [OpenSIPS-Users] Accounting BYE response

I think you should take care of this on your gateway. For example, 
using freeswitch or asterisk, you can check for rtps, and when the 
other end stops sending rtps for 30 seconds (configurable) it will 
tear down the call properly.


Unless you're using a rtp-proxy with opensips which can do this (most 
can), that's the way to do this. Anything else is just duct-taping.


My opinion after 20 years on voip.

Hope that helps.

David

On Fri, Sep 7, 2018, 21:43 Ben Newlin > wrote:


Hi,

I am having an issue trying to add values to accounting based on
the response to the BYE request.

We use the dialog timeout mechanism to terminate long calls in our
system. In some cases, these are “valid” calls that remained
connected for too long due to some error elsewhere in the
application. But sometimes one or both ends of the call believe
they have disconnected, but we did not receive or process the
disconnect, due to a malformed BYE or a network disruption. In
these cases, when the Dialog timeout is reached and OpenSIPS
generates a BYE to both parties, they will respond with a 481.

What I want is to set a CDR flag on receipt of that 481 to
indicate that there was an error and the calculated call time may
not be correct. But it seems that any accounting flags set after
the BYE is sent are not honored. Is there any way to accomplish this?

This is my attempt:

failure_route[local_failure]

{

  $acc_extra(disconnect_error) = "true";

}

local_route

{

  t_on_failure("local_failure");

}

Ben Newlin

___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Delayed timer executions

[Pasan Meemaduma via Users]

Hi Dan,

I'm experiencing same on 2.3.5 as per my initial email. still couldn't find out 
the exact reason. btw are you using a virtualise environment ?
 

On Thursday, 20 September 2018, 7:35:28 PM GMT+5:30, Dan Pascu 
 wrote:  
 
 Here is a follow up on this problem. I started to use the system to do some 
testing. I only have 1 device registered that makes some calls. I started to 
notice similar type of messages, but with a slightly different pattern while 
testing it. They seem to happen more often when I end the call, but I cannot 
unequivocally tie the behavior to that because it doesn't happen always when I 
end a call, it just seems to be triggered more often during that time.

I see a string of warnings about timers that continue for about 30 seconds 
after which they stop, like below (I trimmed the output because it's just 
repeating every 90-100ms and the log would be too long, so I only pasted the 
start and the end of it):

Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 100 ms ago (now 1208830 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 200 ms ago (now 1208930 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 300 ms ago (now 1209030 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 400 ms ago (now 1209130 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 500 ms ago (now 1209230 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 600 ms ago (now 1209330 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 700 ms ago (now 1209430 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 800 ms ago (now 1209530 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 900 ms ago (now 1209630 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: 
timer task  already scheduled 1000 ms ago (now 1209630 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 1000 ms ago (now 1209730 ms), 
delaying execution
Sep 20 10:28:35 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 1100 ms ago (now 1209830 ms), 
delaying execution

[...]

Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 28760 ms ago (now 1237490 ms), 
delaying execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: 
timer task  already scheduled 28860 ms ago (now 1237490 ms), delaying 
execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 28860 ms ago (now 1237590 ms), 
delaying execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 28960 ms ago (now 1237690 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29060 ms ago (now 1237790 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29160 ms ago (now 1237890 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29260 ms ago (now 1237990 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29360 ms ago (now 1238090 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29460 ms ago (now 1238190 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29560 ms ago (now 1238290 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29660 ms ago (now 1238390 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29750 ms ago (now 1238480 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: 
timer task  already scheduled 29850 ms ago (now 1238480 ms), delaying 
execution
Sep 20 10:29:03 node03 

Re: [OpenSIPS-Users] mid_registrar not updating exipres when receiving 200 ok

[Dominic]

Thanks for the reply Liviu, let me know if I can do anything to help, this
is a dev environment so I can try anything on it if it can be usefull.

Dominic

On Thu, Sep 20, 2018 at 10:11 AM Liviu Chircu  wrote:

> Hi Dominic,
>
> The 200 OK returned by OpenSIPS should definitely contain a 120s expiry
> time.  Thanks for the detailed explanation - I will look into this asap.
>
> Best regards,
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 20.09.2018 16:29, Dominic wrote:
>
> Hi all, I have the following setup:
> -sip device is registering to OpenSIPS setup as a mid_registrar who then
> fowards registers to asterisk once they are authenticated
> -OpenSIPS is setup in contact throttling mode with outgoing expires set to
> 3600 sec.
>
> The scenario I came accross is the following:
>
>   "Registration - OpenSips mid_registrar"
>
>┌─┐
>║"│
>└┬┘
>┌┼┐
> │   ┌┐   ┌┐
>┌┴┐  │OpenSips│   │Asterisk│
>   Alice └┘   └┘
> │REGISTER (expires 3600 sec)││
> │───>│
> │   ││
> │ 401 Unauthorized  ││
> │<───│
> │   ││
> │REGISTER (expires 3600 sec)││
> │───>│
> │   ││
> │   │ REGISTER (expires 3600 sec)│
> │   │ ───>
> │   ││
> │   │  200 OK (expires 120 sec)  │
> │   │ <───
> │   ││
> │ 200 OK (expires 3600 sec) ││
> │<───│
> │   ││
> │   ││
> │   ││
> │   ││
>   Alice ┌┐   ┌┐
>┌─┐  │OpenSips│   │Asterisk│
>║"│  └┘   └┘
>└┬┘
>┌┼┐
> │
>┌┴┐
>
>
> 1-the sip device sends a REGISTER to OpenSIPS (expires 3600)
> 2-OpenSIPS authentifies the REGISTER and sends back challenge to the sip
> device
> 3-sip devices sends authenticated REGISTER to OpenSIPS, here the expires
> would normally be changed to 3600 but in this case it was already set at
> 3600.
> 4-Asterisk receives the REGISTER, alters the expires to 120secs and
> replies 200 ok to OpenSIPS
> 5-OpenSIPS forwards the 200 ok but with 3600 sec expires.
>
> My Questions is:
> I was expecting OpenSIPS to automatically update the expires in it's
> usrloc to 120 seconds and send 120 sec in its 200 ok. Should I be doing
> something in a return route for the REGISTERs in order to update that and
> send the correct value or should opensips be doing that automatically?
> Currently I am calling mid_registrar_save("location") when I receive the
> REGISTER but doing nothing when I receive the 200 ok.
>
> Thanks in advance
> Dominic
>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Segmentation fault in master

[Dan Pascu]

I got this crash (memory seems to be corrupted in src->h_addr_list[0]):

Core was generated by `/usr/sbin/opensips -w /run/opensips -P opensips.pid -m 
512'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __memcpy_sse2_unaligned () at 
../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
667 ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file or 
directory.
(gdb) bt
#0  __memcpy_sse2_unaligned () at 
../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:667
#1  0x004faf84 in memcpy (__len=, __src=, 
__dest=0x97e04ad4) at /usr/include/i386-linux-gnu/bits/string3.h:53
#2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
#3  0x96bd108e in shm_clone_proxy (move_dn=, sp=) 
at ../../resolve.h:391
#4  add_uac (t=t@entry=0x97dfc584, request=request@entry=0x96c07240 
, uri=uri@entry=0xbfae0790, next_hop=, 
bflags=, path=, proxy=) at 
t_fwd.c:437
#5  0x96bd442a in t_forward_nonack (t=, p_msg=, 
proxy=, reset_bcounter=, locked=) 
at t_fwd.c:757
#6  0x96b7d5d4 in do_dns_failover (t=t@entry=0x97dfc584) at t_reply.c:702
#7  0x96b7fa44 in t_should_relay_response (Trans=Trans@entry=0x97dfc584, 
new_code=new_code@entry=408, branch=branch@entry=0, should_store=0xbfae0a00, 
should_relay=0xbfae09fc, cancel_bitmap=0xbfae0ad8, reply=0x) at 
t_reply.c:962
#8  0x96b81b84 in relay_reply (t=0x97dfc584, p_msg=0x, branch=0, 
msg_status=408, cancel_bitmap=0xbfae0ad8) at t_reply.c:1206
#9  0x96bcdc0c in fake_reply (code=408, branch=, t=0x97dfc584) 
at timer.c:260
#10 final_response_handler (fr_tl=) at timer.c:399
#11 timer_routine (ticks=1350, set=0x0) at timer.c:1074
#12 0x005422e4 in handle_timer_job () at timer.c:738
#13 0x0061e835 in handle_io (idx=, event_type=, 
fm=) at net/net_udp.c:265
#14 io_wait_loop_epoll (h=, t=, repeat=) at net/../io_wait_loop.h:284
#15 udp_start_processes (chd_rank=0x759980 , startup_done=0x0) at 
net/net_udp.c:389
#16 0x004d7418 in main_loop () at main.c:755
#17 main (argc=, argv=) at main.c:1407
(gdb) frame 2
#2  hostent_shm_cpy (dst=0x97e11bcc, src=0x97df1d8c) at proxy.c:75
75  proxy.c: No such file or directory.
(gdb) print *src
$1 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 2, h_length = 4, h_addr_list 
= 0x97df1dd8}
(gdb) print *dst
$2 = {h_name = 0x0, h_aliases = 0x0, h_addrtype = 0, h_length = 0, h_addr_list 
= 0x97e04abc}
(gdb) print src->h_addr_list[0]
$4 = 0x22e1f08 
(gdb) print src->h_addr_list[1]
$5 = 0x97df1dec "Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
(gdb) print src->h_addr_list[2]
$6 = 0x97df1de8 
"Q\027\344\226Q\027\344\201U\021\272\a\300\300\300\300\355\357ͫ\227\225"
(gdb) print src->h_addr_list[3]
$7 = 0x0

--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] mid_registrar not updating exipres when receiving 200 ok

[Liviu Chircu]

Hi Dominic,

The 200 OK returned by OpenSIPS should definitely contain a 120s expiry 
time.  Thanks for the detailed explanation - I will look into this asap.


Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 20.09.2018 16:29, Dominic wrote:

Hi all, I have the following setup:
-sip device is registering to OpenSIPS setup as a mid_registrar who 
then fowards registers to asterisk once they are authenticated
-OpenSIPS is setup in contact throttling mode with outgoing expires 
set to 3600 sec.


The scenario I came accross is the following:

   "Registration - OpenSips mid_registrar"

┌─┐

║"│
└┬┘
┌┼┐
 │   ┌┐   ┌┐
┌┴┐  │OpenSips│   │Asterisk│
   Alice └┘   └┘
 │REGISTER (expires 3600 sec)││
 │───>│
 │   ││
 │ 401 Unauthorized  ││
 │<───│
 │   ││
 │REGISTER (expires 3600 sec)││
 │───>│
 │   ││
 │   │ REGISTER (expires 3600 sec)│
 │   │ ───>
 │   ││
 │   │  200 OK (expires 120 sec)  │
 │   │ <───
 │   ││
 │ 200 OK (expires 3600 sec) ││
 │<───│
 │   ││
 │   ││
 │   ││
 │   ││
   Alice ┌┐   ┌┐
┌─┐  │OpenSips│   │Asterisk│
║"│  └┘   └┘
└┬┘
┌┼┐
 │
┌┴┐

1-the sip device sends a REGISTER to OpenSIPS (expires 3600)
2-OpenSIPS authentifies the REGISTER and sends back challenge to the 
sip device
3-sip devices sends authenticated REGISTER to OpenSIPS, here the 
expires would normally be changed to 3600 but in this case it was 
already set at 3600.
4-Asterisk receives the REGISTER, alters the expires to 120secs and 
replies 200 ok to OpenSIPS

5-OpenSIPS forwards the 200 ok but with 3600 sec expires.

My Questions is:
I was expecting OpenSIPS to automatically update the expires in it's 
usrloc to 120 seconds and send 120 sec in its 200 ok. Should I be 
doing something in a return route for the REGISTERs in order to update 
that and send the correct value or should opensips be doing that 
automatically? Currently I am calling mid_registrar_save("location") 
when I receive the REGISTER but doing nothing when I receive the 200 ok.


Thanks in advance
Dominic



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Delayed timer executions

[Dan Pascu]

Here is a follow up on this problem. I started to use the system to do some 
testing. I only have 1 device registered that makes some calls. I started to 
notice similar type of messages, but with a slightly different pattern while 
testing it. They seem to happen more often when I end the call, but I cannot 
unequivocally tie the behavior to that because it doesn't happen always when I 
end a call, it just seems to be triggered more often during that time.

I see a string of warnings about timers that continue for about 30 seconds 
after which they stop, like below (I trimmed the output because it's just 
repeating every 90-100ms and the log would be too long, so I only pasted the 
start and the end of it):

Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 100 ms ago (now 1208830 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 200 ms ago (now 1208930 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 300 ms ago (now 1209030 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 400 ms ago (now 1209130 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 500 ms ago (now 1209230 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 600 ms ago (now 1209330 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 700 ms ago (now 1209430 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 800 ms ago (now 1209530 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 900 ms ago (now 1209630 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: 
timer task  already scheduled 1000 ms ago (now 1209630 ms), delaying 
execution
Sep 20 10:28:34 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 1000 ms ago (now 1209730 ms), 
delaying execution
Sep 20 10:28:35 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 1100 ms ago (now 1209830 ms), 
delaying execution

[...]

Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 28760 ms ago (now 1237490 ms), 
delaying execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: 
timer task  already scheduled 28860 ms ago (now 1237490 ms), delaying 
execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 28860 ms ago (now 1237590 ms), 
delaying execution
Sep 20 10:29:02 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 28960 ms ago (now 1237690 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29060 ms ago (now 1237790 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29160 ms ago (now 1237890 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29260 ms ago (now 1237990 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29360 ms ago (now 1238090 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29460 ms ago (now 1238190 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29560 ms ago (now 1238290 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29660 ms ago (now 1238390 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29750 ms ago (now 1238480 ms), 
delaying execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:timer_ticker: 
timer task  already scheduled 29850 ms ago (now 1238480 ms), delaying 
execution
Sep 20 10:29:03 node03 /usr/sbin/opensips[30302]: WARNING:core:utimer_ticker: 
utimer task  already scheduled 29850 ms ago (now 1238580 ms), 
delaying execution

On 17 Sep 2018, at 12:30, Dan Pascu wrote:

> 
> I quite often find these warnings in syslog. They happen on an 

[OpenSIPS-Users] mid_registrar not updating exipres when receiving 200 ok

[Dominic]

Hi all, I have the following setup:
-sip device is registering to OpenSIPS setup as a mid_registrar who then
fowards registers to asterisk once they are authenticated
-OpenSIPS is setup in contact throttling mode with outgoing expires set to
3600 sec.

The scenario I came accross is the following:

  "Registration - OpenSips mid_registrar"

   ┌─┐
   ║"│
   └┬┘
   ┌┼┐
│   ┌┐   ┌┐
   ┌┴┐  │OpenSips│   │Asterisk│
  Alice └┘   └┘
│REGISTER (expires 3600 sec)││
│───>│
│   ││
│ 401 Unauthorized  ││
│<───│
│   ││
│REGISTER (expires 3600 sec)││
│───>│
│   ││
│   │ REGISTER (expires 3600 sec)│
│   │ ───>
│   ││
│   │  200 OK (expires 120 sec)  │
│   │ <───
│   ││
│ 200 OK (expires 3600 sec) ││
│<───│
│   ││
│   ││
│   ││
│   ││
  Alice ┌┐   ┌┐
   ┌─┐  │OpenSips│   │Asterisk│
   ║"│  └┘   └┘
   └┬┘
   ┌┼┐
│
   ┌┴┐


1-the sip device sends a REGISTER to OpenSIPS (expires 3600)
2-OpenSIPS authentifies the REGISTER and sends back challenge to the sip
device
3-sip devices sends authenticated REGISTER to OpenSIPS, here the expires
would normally be changed to 3600 but in this case it was already set at
3600.
4-Asterisk receives the REGISTER, alters the expires to 120secs and replies
200 ok to OpenSIPS
5-OpenSIPS forwards the 200 ok but with 3600 sec expires.

My Questions is:
I was expecting OpenSIPS to automatically update the expires in it's usrloc
to 120 seconds and send 120 sec in its 200 ok. Should I be doing something
in a return route for the REGISTERs in order to update that and send the
correct value or should opensips be doing that automatically? Currently I
am calling mid_registrar_save("location") when I receive the REGISTER but
doing nothing when I receive the 200 ok.

Thanks in advance
Dominic
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users