Re: [asterisk-users] RTCP + Stasis causing high memory consumption

2017-11-15 Thread Patrick Wakano 
Thank you very much for the response Matthew!
I'll try the stasis configuration change first.
I can't say if a malformed RTCP packet triggered the issue, but I did
actually checked a tcpdump while problem was happening and the amount of
RTCP packets and AMI events were reasonably normal Apparently it is an
internal only problem, not actually outputting abnormal traffic in the
network

Best regards!
Patrick Wakano

On 16 November 2017 at 02:34, Matthew Jordan  wrote:

>
>
> On Mon, Nov 13, 2017 at 11:42 PM, Patrick Wakano 
> wrote:
>
>> Hello Asterisk list,
>>
>> I've facing a memory allocation issue that happens occasionally but on a
>> consistent basis.
>> The problem happens as follow, suddenly Asterisk starts consuming a lot
>> of memory, in a rate of more than 1GB per hour. Kernel will eventually kill
>> it via the OOM killer when memory is really exausted... This situation does
>> not generate backtrace because Asterisk is responsive during the whole time
>> and can be stopped/started.
>> After compiling Asterisk with the MALLOC_DEBUG flag, when the problem
>> happened we could see this output with the most consuming files, using
>> "memory show summary" command:
>> # cat memory_show_summary_201711101144.log | sort -nr | head
>> 3060904798 bytes allocated (431496 in caches) in 16185877 allocations
>> 1467180225 bytes in1647238 allocations in file stasis_channels.c
>> 1217035109 bytes in   10229320 allocations in file json.c
>>  240064732 bytes in1765287 allocations in file stasis_message.c
>>   56402000 bytes in1762250 allocations in file taskprocessor.c
>>   26125344 bytes in 203171 allocations in file rtp_engine.c
>>   17308827 bytes in 307848 allocations in file stasis_cache.c
>>9548128 bytes in  35482 allocations in file stasis_bridges.c
>>3923172 bytes in  92169 allocations in file res_rtp_asterisk.c
>>3099771 bytes in  29185 allocations in file strings.c
>>
>> Next minute it was already like this:
>> # cat memory_show_summary_201711101145.log | sort -nr | head
>> 3091009032 bytes allocated (375561 in caches) in 16345842 allocations
>> 1482476997 bytes in1663899 allocations in file stasis_channels.c
>> 1228978956 bytes in   10329516 allocations in file json.c
>>  242483220 bytes in1783070 allocations in file stasis_message.c
>>   57063120 bytes in1782910 allocations in file taskprocessor.c
>>   26354360 bytes in 205090 allocations in file rtp_engine.c
>>   17481272 bytes in 310935 allocations in file stasis_cache.c
>>9628576 bytes in  35782 allocations in file stasis_bridges.c
>>3828232 bytes in  93040 allocations in file res_rtp_asterisk.c
>>3125118 bytes in  29427 allocations in file strings.c
>>
>> So as we can see, total allocations increased 159965 or 30MB in one
>> minute..
>> A regular "memory show summary" during the day would be like this:
>> # cat memory_show_summary_201711140400.log | sort -nr | head
>> 30595537 bytes allocated (406915 in caches) in 77906 allocations
>> 11021007 bytes in   5081 allocations in file stasis_channels.c
>>  3825007 bytes in  12643 allocations in file cdr.c
>>  1855344 bytes in  15837 allocations in file pbx.c
>>  1766744 bytes in183 allocations in file translate.c
>>  1467681 bytes in   1451 allocations in file chan_sip.c
>>  140 bytes in280 allocations in file res_rtp_asterisk.c
>>   980474 bytes in   4740 allocations in file xmldoc.c
>>   895369 bytes in167 allocations in file file.c
>>   800900 bytes in   2397 allocations in file channel.c
>>   280728 bytes in613 allocations in file rtp_engine.c
>>   243147 bytes in   2556 allocations in file stasis.c
>>   130066 bytes in   1082 allocations in file stasis_cache.c
>>24928 bytes in 82 allocations in file stasis_bridges.c
>>51796 bytes in486 allocations in file stasis_message.c
>>
>> We also tried to get a "memory show allocations" when the problem was
>> happening. Unsurprisingly it halted Asterisk and after we cancelled it, it
>> had generated a 1GB file. Both memory logs hinted us to some problem in the
>> RTP module, specifically in the RTCP handling. After investigating the
>> code, looks like for some reason, the res_rtp_asterisk.c (line 4116) when
>> doing the ast_rtcp_read() ended up entering in a loop, causing lots of
>> allocations in the rtp_engine.c (line 2047 - ast_rtp_publish_rtcp_message).
>> Also apparently, another loop (or maybe the same, not sure...) happened
>> calling ast_channel_publish_blob() because we got lots of
>> create_channel_blob_message and ast_channel_snapshot_create allocations too.
>> Json, taskprocessor, stasis_message and stasis_cache allocations seems to
>> be side effect of so many stasis messages being created and published.
>> We could check memory logs 3 times for this problem and they are similar
>> so it seems that a bug exists

Re: [asterisk-users] Is it safe to configure SIP/Registry entries on a passive asterisk node ?

2017-11-15 Thread Jean Aunis 

Le 15/11/2017 à 17:30, Olivier a écrit :

Hello,

I've seen that Asterisk stores in ASTDB entries like:
/SIP/Registry/spa3102 : 
192.168.64.207:5060 
:3600:7013:sip:spa3102@192.168.64.207:5060 



1. My understanding is that any peer that sent to Asterisk a REGISTER 
message has such entry set. So having these entries present avoid for 
a starting Asterisk the need to way for incoming REGISTER messages 
which can be as long as 30mn to come in my use case.

Is it roughly correct or am I missing something ?

2. When configuring a passive Asterisk node (waiting for an active 
node to be manually shutdown),  is it safe to copy such SIP/Registry 
entries from one node to another ?

Both active and passive nodes will get Debian's packaged Asterisk 13.14.1.

3. How is best to set such SIP/Registry entries ?
Using SQLite load command when asterisk is not running and asterisk 
-rx "database put SIP/Registry ..." when asterisk is running ?



Cheers


I did something like this in the past. We had a cluster of two nodes 
sharing a virtual IP address. The whole AstDb file was just copied from 
the active to the passive node, with a protocol like rsync or something 
similar.
It worked well. Then, is it totally safe ? We did not encounter any 
particular issue during our tests or in our production environments. 
Still, you may find theoretical edge cases which could be problematic. 
For example, copying the file is not an atomic operation, so what 
happens if Asterisk starts but the file has not been entirely copied ?
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Confbridge SFU for Asterisk 15

2017-11-15 Thread Carlos Chavez 

On 11/15/17 11:36 AM, Joshua Colp wrote:


On Wed, Nov 15, 2017, at 01:30 PM, Carlos Chavez wrote:




Here is more information from the browser about the session:
https://pbxoficina.telecomabmex.com/nextcloud/index.php/s/af36iLlljtbYkbF

On Asterisk I have icesupport=true in rtp.conf and ice_support=yes on the
endpoint.  I have configured a STUN server in both rtp.conf and
res_stun_monitor.conf

What is the exact network topology? Is Asterisk behind NAT as well with
ports forwarded? If so you should configure a mapping in rtp.conf so
that the internal IP address is mapped to its external IP address in the
ICE candidates, giving a better chance that things will work.

Correct, Asterisk is behind a NAT with SIP and RTP forwarded to the 
server.  We have a static IP address set in the transport definition.  I 
will map the port in rtp.conf and try it again.


--
Telecomunicaciones Abiertas de México S.A. de C.V.
Carlos Chávez
+52 (55)8116-9161


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] SSRC =0x0 in RTP

2017-11-15 Thread Joshua Colp 
On Wed, Nov 15, 2017, at 01:37 PM, Harel Cohen wrote:
> >
> > Hi Joshua,
> 
> > Thank you for looking into this.
> 
> > Their response IS based on traces I've sent them. Attached is such trace
> in text format (server IP has been changed to 111.111.111.111). Some
> repeating RTP packets has been truncated.
> You can see that after the 200 OK SSRC is sent from the server to the
> phone
> as '0x0'. The same has happened with G729 codec.
> 
> > Let me know if you need the full trace or anything else from my side.
> 
> > I should also mention that this is Asterisk version 1.8.12.1

I'm sorry but this version is old enough that what I currently know is
far past it. It may have been possible in that old version for the SSRC
to be as you state. In recent stuff it doesn't seem to be possible.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] SSRC =0x0 in RTP

2017-11-15 Thread Harel Cohen 
>
> Hi Joshua,

> Thank you for looking into this.

> Their response IS based on traces I've sent them. Attached is such trace
in text format (server IP has been changed to 111.111.111.111). Some
repeating RTP packets has been truncated.
You can see that after the 200 OK SSRC is sent from the server to the phone
as '0x0'. The same has happened with G729 codec.

> Let me know if you need the full trace or anything else from my side.

> I should also mention that this is Asterisk version 1.8.12.1

> Thank you

> Harel

> --

>
On Tue, Nov 14, 2017, at 09:14 AM, Harel Cohen wrote:

> > Hello,

> > I have a problem where on an outgoing call a Grandstream phone

> > (GXP2130) closes the incoming voice stream about 1 second into the

> > call (the remote party hears the Grandstream, the Grandstream doesn't

> > hear thr remote party). I have verified with logs and traces that this

> > is not a NAT issue or any other network-related problem. All incoming

> > RTP packets arrive at the phone on the correct port etc. as declared in
the SDP.

> > I opened a ticket with Grandstream and they replied: "

> >

> > *the phone starts receiving RTP with SSRC =0x0 which is wrong".*

> >

> > Is this an Asterisk problem or the phones? Is this something that can

> > be fixed on the Asterisk side?

>
Asterisk would be sending the RTP to the Grandstream. I'd suggest getting a
packet capture using tcpdump or wireshark to confirm what they've said
though. I just looked at the code and I don't see a way that we'd ever have
the SSRC be 0.

>
Cheers,

>
--

> Joshua Colp

> Digium, Inc. | Senior Software Developer

> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at:
www.digium.com & www.asterisk.org

>

>
No. Time   SourceDestination   Protocol 
Length Info
  1 0.00
1224   

Frame 1: 1224 bytes on wire (9792 bits), 1224 bytes captured (9792 bits)
This frame is marked as ignored

No. Time   SourceDestination   Protocol 
Length Info
  2 0.078267   195.191.156.50192.168.10.144SIP  631 
   Status: 401 Unauthorized | 

Frame 2: 631 bytes on wire (5048 bits), 631 bytes captured (5048 bits)
Ethernet II, Src: 00:ff:6b:60:2c:4c (00:ff:6b:60:2c:4c), Dst: Grandstr_a7:a0:fa 
(00:0b:82:a7:a0:fa)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 0
Internet Protocol Version 4, Src: 195.191.156.50, Dst: 192.168.10.144
User Datagram Protocol, Src Port: 55060, Dst Port: 21321
Session Initiation Protocol (401)

No. Time   SourceDestination   Protocol 
Length Info
  3 0.090271   192.168.10.144195.191.156.50SIP  431 
   Request: ACK sip:0035699143...@sip1.mayorcom.com:55060 | 

Frame 3: 431 bytes on wire (3448 bits), 431 bytes captured (3448 bits)
Ethernet II, Src: Grandstr_a7:a0:fa (00:0b:82:a7:a0:fa), Dst: 00:ff:6b:60:2c:4c 
(00:ff:6b:60:2c:4c)
Internet Protocol Version 4, Src: 192.168.10.144, Dst: 195.191.156.50
User Datagram Protocol, Src Port: 21321, Dst Port: 55060
Session Initiation Protocol (ACK)

No. Time   SourceDestination   Protocol 
Length Info
  4 0.120599   192.168.10.144195.191.156.50SIP/SDP  
1427   Request: INVITE sip:0035699143...@sip1.mayorcom.com:55060 | 

Frame 4: 1427 bytes on wire (11416 bits), 1427 bytes captured (11416 bits)
Ethernet II, Src: Grandstr_a7:a0:fa (00:0b:82:a7:a0:fa), Dst: 00:ff:6b:60:2c:4c 
(00:ff:6b:60:2c:4c)
Internet Protocol Version 4, Src: 192.168.10.144, Dst: 195.191.156.50
User Datagram Protocol, Src Port: 21321, Dst Port: 55060
Session Initiation Protocol (INVITE)

No. Time   SourceDestination   Protocol 
Length Info
  5 0.200309   195.191.156.50192.168.10.144SIP  576 
   Status: 100 Trying | 

Frame 5: 576 bytes on wire (4608 bits), 576 bytes captured (4608 bits)
Ethernet II, Src: 00:ff:6b:60:2c:4c (00:ff:6b:60:2c:4c), Dst: Grandstr_a7:a0:fa 
(00:0b:82:a7:a0:fa)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 0
Internet Protocol Version 4, Src: 195.191.156.50, Dst: 192.168.10.144
User Datagram Protocol, Src Port: 55060, Dst Port: 21321
Session Initiation Protocol (100)

No. Time   SourceDestination   Protocol 
Length Info
  6 1.742472   195.191.156.50192.168.10.144SIP/SDP  883 
   Status: 183 Session Progress | 

Frame 6: 883 bytes on wire (7064 bits), 883 bytes captured (7064 bits)
Ethernet II, Src: 00:ff:6b:60:2c:4c (00:ff:6b:60:2c:4c), Dst: Grandstr_a7:a0:fa 
(00:0b:82:a7:a0:fa)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 0
Internet Protocol Version 4, Src: 195.191.156.50, Dst: 192.168.10.144
User Datagram Protocol, Src Port: 55060, Dst Port: 21321
Session Initiation Protocol (183)

No. Time   SourceDestination   Protocol 
Length

Re: [asterisk-users] Confbridge SFU for Asterisk 15

2017-11-15 Thread Joshua Colp 
On Wed, Nov 15, 2017, at 01:30 PM, Carlos Chavez wrote:



> Here is more information from the browser about the session:
> https://pbxoficina.telecomabmex.com/nextcloud/index.php/s/af36iLlljtbYkbF
> 
> On Asterisk I have icesupport=true in rtp.conf and ice_support=yes on the
> endpoint.  I have configured a STUN server in both rtp.conf and
> res_stun_monitor.conf

What is the exact network topology? Is Asterisk behind NAT as well with
ports forwarded? If so you should configure a mapping in rtp.conf so
that the internal IP address is mapped to its external IP address in the
ICE candidates, giving a better chance that things will work.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Confbridge SFU for Asterisk 15

2017-11-15 Thread Carlos Chavez 

On 11/15/17 11:10 AM, Joshua Colp wrote:


On Wed, Nov 15, 2017, at 01:05 PM, Carlos Chavez wrote:

On 11/14/17 5:23 PM, Joshua Colp wrote:


On Tue, Nov 14, 2017, at 07:19 PM, Carlos Chavez wrote:

Trace with 3 clients.  We can hear each other but no video.

https://pbxoficina.telecomabmex.com/nextcloud/index.php/s/X0PQ5FrYeqCwwkz

Do you see anything in the Javascript console of the browser? We are
adding the needed media streams by sending a reinvite to the
participants but we don't get any response, which means for some reason
the browser may not have liked what we provided.


This is what I get on the console:
new session - outgoing - [object Object]
cyber_mega_phone.js:78:3
ontrack: audio - 8b7fca5e-bb67-4e8c-8bdb-84fb80ac4cc0 stream
66e4250b-c196-4482-a347-d12772ef865d
cyber_mega_phone.js:111:4
Streams: added 66e4250b-c196-4482-a347-d12772ef865d
cyber_mega_phone.js:225:3
ontrack: video - ad836e20-c0c9-423f-9c42-0aef19c5ca32 stream
66e4250b-c196-4482-a347-d12772ef865d
cyber_mega_phone.js:111:4
confirmed: adding local stream {8bafb537-864a-424b-b5d3-d13ee0b60f8c}
cyber_mega_phone.js:84:5
Streams: added {8bafb537-864a-424b-b5d3-d13ee0b60f8c}
cyber_mega_phone.js:225:3
RTCPeerConnection.getLocalStreams/getRemoteStreams are deprecated. Use
RTCPeerConnection.getSenders/getReceivers instead.
cyber_mega_phone.js:82:17
ICE failed, add a STUN server and see about:webrtc for more details

Looks like for some reason it failed to successfully do ICE negotiation
potentially on the newly added remote streams. Why that is is
environment specific - but the problem does seem to be on the web
browser/client side, not in Asterisk itself. You'd need to figure out
why.

This is one of the annoyances of WebRTC - the browser can be a black box
at time and when things go wrong (like this) it's hard to dig and figure
out what is up.


Here is more information from the browser about the session:
https://pbxoficina.telecomabmex.com/nextcloud/index.php/s/af36iLlljtbYkbF

On Asterisk I have icesupport=true in rtp.conf and ice_support=yes on the 
endpoint.  I have configured a STUN server in both rtp.conf and 
res_stun_monitor.conf


--
Telecomunicaciones Abiertas de México S.A. de C.V.
Carlos Chávez
+52 (55)8116-9161


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Confbridge SFU for Asterisk 15

2017-11-15 Thread Joshua Colp 
On Wed, Nov 15, 2017, at 01:05 PM, Carlos Chavez wrote:
> On 11/14/17 5:23 PM, Joshua Colp wrote:
> 
> > On Tue, Nov 14, 2017, at 07:19 PM, Carlos Chavez wrote:
> >> Trace with 3 clients.  We can hear each other but no video.
> >>
> >> https://pbxoficina.telecomabmex.com/nextcloud/index.php/s/X0PQ5FrYeqCwwkz
> > Do you see anything in the Javascript console of the browser? We are
> > adding the needed media streams by sending a reinvite to the
> > participants but we don't get any response, which means for some reason
> > the browser may not have liked what we provided.
> >
> This is what I get on the console:
> new session - outgoing - [object Object]
> cyber_mega_phone.js:78:3
> ontrack: audio - 8b7fca5e-bb67-4e8c-8bdb-84fb80ac4cc0 stream 
> 66e4250b-c196-4482-a347-d12772ef865d
> cyber_mega_phone.js:111:4
> Streams: added 66e4250b-c196-4482-a347-d12772ef865d
> cyber_mega_phone.js:225:3
> ontrack: video - ad836e20-c0c9-423f-9c42-0aef19c5ca32 stream 
> 66e4250b-c196-4482-a347-d12772ef865d
> cyber_mega_phone.js:111:4
> confirmed: adding local stream {8bafb537-864a-424b-b5d3-d13ee0b60f8c}
> cyber_mega_phone.js:84:5
> Streams: added {8bafb537-864a-424b-b5d3-d13ee0b60f8c}
> cyber_mega_phone.js:225:3
> RTCPeerConnection.getLocalStreams/getRemoteStreams are deprecated. Use 
> RTCPeerConnection.getSenders/getReceivers instead.
> cyber_mega_phone.js:82:17
> ICE failed, add a STUN server and see about:webrtc for more details

Looks like for some reason it failed to successfully do ICE negotiation
potentially on the newly added remote streams. Why that is is
environment specific - but the problem does seem to be on the web
browser/client side, not in Asterisk itself. You'd need to figure out
why.

This is one of the annoyances of WebRTC - the browser can be a black box
at time and when things go wrong (like this) it's hard to dig and figure
out what is up.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Confbridge SFU for Asterisk 15

2017-11-15 Thread Carlos Chavez 

On 11/14/17 5:23 PM, Joshua Colp wrote:


On Tue, Nov 14, 2017, at 07:19 PM, Carlos Chavez wrote:

Trace with 3 clients.  We can hear each other but no video.

https://pbxoficina.telecomabmex.com/nextcloud/index.php/s/X0PQ5FrYeqCwwkz

Do you see anything in the Javascript console of the browser? We are
adding the needed media streams by sending a reinvite to the
participants but we don't get any response, which means for some reason
the browser may not have liked what we provided.


This is what I get on the console:
new session - outgoing - [object Object]
cyber_mega_phone.js:78:3
ontrack: audio - 8b7fca5e-bb67-4e8c-8bdb-84fb80ac4cc0 stream 
66e4250b-c196-4482-a347-d12772ef865d

cyber_mega_phone.js:111:4
Streams: added 66e4250b-c196-4482-a347-d12772ef865d
cyber_mega_phone.js:225:3
ontrack: video - ad836e20-c0c9-423f-9c42-0aef19c5ca32 stream 
66e4250b-c196-4482-a347-d12772ef865d

cyber_mega_phone.js:111:4
confirmed: adding local stream {8bafb537-864a-424b-b5d3-d13ee0b60f8c}
cyber_mega_phone.js:84:5
Streams: added {8bafb537-864a-424b-b5d3-d13ee0b60f8c}
cyber_mega_phone.js:225:3
RTCPeerConnection.getLocalStreams/getRemoteStreams are deprecated. Use 
RTCPeerConnection.getSenders/getReceivers instead.

cyber_mega_phone.js:82:17
ICE failed, add a STUN server and see about:webrtc for more details

--
Telecomunicaciones Abiertas de México S.A. de C.V.
Carlos Chávez
+52 (55)8116-9161


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Is it safe to configure SIP/Registry entries on a passive asterisk node ?

2017-11-15 Thread Olivier 
Hello,

I've seen that Asterisk stores in ASTDB entries like:
/SIP/Registry/spa3102 : 192.168.64.207:5060:
3600:7013:sip:spa3102@192.168.64.207:5060

1. My understanding is that any peer that sent to Asterisk a REGISTER
message has such entry set. So having these entries present avoid for a
starting Asterisk the need to way for incoming REGISTER messages which can
be as long as 30mn to come in my use case.
Is it roughly correct or am I missing something ?

2. When configuring a passive Asterisk node (waiting for an active node to
be manually shutdown),  is it safe to copy such SIP/Registry entries from
one node to another ?
Both active and passive nodes will get Debian's packaged Asterisk 13.14.1.

3. How is best to set such SIP/Registry entries ?
Using SQLite load command when asterisk is not running and asterisk -rx
"database put SIP/Registry ..." when asterisk is running ?


Cheers
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] RTCP + Stasis causing high memory consumption

2017-11-15 Thread Matthew Jordan 
On Mon, Nov 13, 2017 at 11:42 PM, Patrick Wakano  wrote:

> Hello Asterisk list,
>
> I've facing a memory allocation issue that happens occasionally but on a
> consistent basis.
> The problem happens as follow, suddenly Asterisk starts consuming a lot of
> memory, in a rate of more than 1GB per hour. Kernel will eventually kill it
> via the OOM killer when memory is really exausted... This situation does
> not generate backtrace because Asterisk is responsive during the whole time
> and can be stopped/started.
> After compiling Asterisk with the MALLOC_DEBUG flag, when the problem
> happened we could see this output with the most consuming files, using
> "memory show summary" command:
> # cat memory_show_summary_201711101144.log | sort -nr | head
> 3060904798 bytes allocated (431496 in caches) in 16185877 allocations
> 1467180225 bytes in1647238 allocations in file stasis_channels.c
> 1217035109 bytes in   10229320 allocations in file json.c
>  240064732 bytes in1765287 allocations in file stasis_message.c
>   56402000 bytes in1762250 allocations in file taskprocessor.c
>   26125344 bytes in 203171 allocations in file rtp_engine.c
>   17308827 bytes in 307848 allocations in file stasis_cache.c
>9548128 bytes in  35482 allocations in file stasis_bridges.c
>3923172 bytes in  92169 allocations in file res_rtp_asterisk.c
>3099771 bytes in  29185 allocations in file strings.c
>
> Next minute it was already like this:
> # cat memory_show_summary_201711101145.log | sort -nr | head
> 3091009032 bytes allocated (375561 in caches) in 16345842 allocations
> 1482476997 bytes in1663899 allocations in file stasis_channels.c
> 1228978956 bytes in   10329516 allocations in file json.c
>  242483220 bytes in1783070 allocations in file stasis_message.c
>   57063120 bytes in1782910 allocations in file taskprocessor.c
>   26354360 bytes in 205090 allocations in file rtp_engine.c
>   17481272 bytes in 310935 allocations in file stasis_cache.c
>9628576 bytes in  35782 allocations in file stasis_bridges.c
>3828232 bytes in  93040 allocations in file res_rtp_asterisk.c
>3125118 bytes in  29427 allocations in file strings.c
>
> So as we can see, total allocations increased 159965 or 30MB in one
> minute..
> A regular "memory show summary" during the day would be like this:
> # cat memory_show_summary_201711140400.log | sort -nr | head
> 30595537 bytes allocated (406915 in caches) in 77906 allocations
> 11021007 bytes in   5081 allocations in file stasis_channels.c
>  3825007 bytes in  12643 allocations in file cdr.c
>  1855344 bytes in  15837 allocations in file pbx.c
>  1766744 bytes in183 allocations in file translate.c
>  1467681 bytes in   1451 allocations in file chan_sip.c
>  140 bytes in280 allocations in file res_rtp_asterisk.c
>   980474 bytes in   4740 allocations in file xmldoc.c
>   895369 bytes in167 allocations in file file.c
>   800900 bytes in   2397 allocations in file channel.c
>   280728 bytes in613 allocations in file rtp_engine.c
>   243147 bytes in   2556 allocations in file stasis.c
>   130066 bytes in   1082 allocations in file stasis_cache.c
>24928 bytes in 82 allocations in file stasis_bridges.c
>51796 bytes in486 allocations in file stasis_message.c
>
> We also tried to get a "memory show allocations" when the problem was
> happening. Unsurprisingly it halted Asterisk and after we cancelled it, it
> had generated a 1GB file. Both memory logs hinted us to some problem in the
> RTP module, specifically in the RTCP handling. After investigating the
> code, looks like for some reason, the res_rtp_asterisk.c (line 4116) when
> doing the ast_rtcp_read() ended up entering in a loop, causing lots of
> allocations in the rtp_engine.c (line 2047 - ast_rtp_publish_rtcp_message).
> Also apparently, another loop (or maybe the same, not sure...) happened
> calling ast_channel_publish_blob() because we got lots of
> create_channel_blob_message and ast_channel_snapshot_create allocations too.
> Json, taskprocessor, stasis_message and stasis_cache allocations seems to
> be side effect of so many stasis messages being created and published.
> We could check memory logs 3 times for this problem and they are similar
> so it seems that a bug exists somewhere leading to this problem.
> So anyone has any idea of what could be happening or if it may be related
> to some known bug?
> We are running Asterisk 13.6.0 in CentOS 6.6.
>
>
There have been a lot of bug fixes in this area since Asterisk 13.6.0. I'd
highly recommend upgrading your version of Asterisk to the latest 13.x to
see if it resolves the issue.

If not, and you don't need the RTCP related events in either AMI or ARI,
you can permanently disable them in stasis.conf:

[declined_message_types]
decline=ast_rtp_rtcp_sent_type

decline=ast_rtp_rtcp_received_type

While