[asterisk-users] Issue with DAHDI and caller id after update

[Chad Mothersell]

Hello Asterisk users,
This issue started after we updated all of our systems to Asterisk 13.7.2.
Details:
CentOS 5.11
DAHDI Version: 2.9.1.1
Asterisk updated from 13.1.0 to 13.7.2
Asterisk takes around 5 rings to answer the call (before it took 2)
Only seems to happen to our Asterisk systems behind another phone system that 
does not provide caller ID
Asterisk systems connected directly to a telco that doesn’t provide caller ID 
work fine
All systems that get caller ID work fine

Disabling caller ID in chan_dahdi.conf allows Asterisk to answer the call 
immediately. This does fix the issue but we manage a large amount of Asterisk 
servers and we follow “same is good, different is bad”. We’ve never had to 
track this setting before on our systems because before if there was no caller 
ID Asterisk would just move on after two rings. This makes sense because caller 
ID should arrive between one and two rings on an analog line.

Just wondering if anyone else may have ran into a similar issue and was able to 
resolve it. 

Thanks!

Chad-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] AST-2016-005: TCP denial of service in PJProject

[Asterisk Security Team]

   Asterisk Project Security Advisory - AST-2016-005

 ProductAsterisk  
 SummaryTCP denial of service in PJProject
Nature of Advisory  Crash/Denial of Service   
  SusceptibilityRemote Unauthenticated Sessions   
 Severity   Critical  
  Exploits KnownNo
   Reported On  February 15, 2016 
   Reported By  George Joseph 
Posted On   
 Last Updated OnMarch 3, 2016 
 Advisory Contact   Mark Michelson   
 CVE Name   

Description  PJProject has a limit on the number of TCP connections that  
 it can accept. Furthermore, PJProject does not close TCP 
 connections it accepts. By default, this value is
 approximately 60.
  
 An attacker can deplete the number of allowed TCP
 connections by opening TCP connections and sending no data   
 to Asterisk. 
  
 If PJProject has been compiled in debug mode, then once the  
 number of allowed TCP connections has been depleted, the 
 next attempted TCP connection to Asterisk will crash due to  
 an assertion in PJProject.   
  
 If PJProject has not been compiled in debug mode, then any   
 further TCP connection attempts will be rejected. This   
 makes Asterisk unable to process TCP SIP traffic.
  
 Note that this only affects TCP/TLS, since UDP is
 connectionless. Also note that this does not affect  
 chan_sip.

Resolution  PJProject has a compile-time constant that controls the   
maximum number of TCP connections that can be handled. Those  
who compile PJProject on their own are encouraged to set  
this to a value that is more amenable to the number of TCP
connections that Asterisk should be able to handle. In
PJProject's pjlib/include/pj/config_site.h, add the   
following prior to compiling PJProject:   
  
# define PJ_IOQUEUE_MAX_HANDLES (FD_SETSIZE)  
  
This is part of a larger set of recommended definitions to
place in config_site.h of PJProject. See the Asterisk 
"Building and Installing PJProject" wiki page for other   
recommended settings. 
  
Packagers of PJProject have updated their packages to have
these constants defined, so if your package is kept up to 
date, you should already be fine. 
  
In addition, the Asterisk project has recently been modified  
to be able to perform a static build of PJProject. By 
running the Asterisk configure script with the
--with-pjproject-bundled option, the latest PJProject will
be downloaded and installed, and the compile-time constants   
will be set to appropriate values.
  
Asterisk has also been updated to monitor incoming TCP
connections. If a TCP connection is opened and no SIP 
request is received on that connection within a certain   
amount of time, then Asterisk will shut down the connection.  

   Affected Versions  

[asterisk-users] AST-2016-004: Long Contact URIs in REGISTER requests can crash Asterisk

[Asterisk Security Team]

   Asterisk Project Security Advisory - AST-2016-004

 ProductAsterisk  
 SummaryLong Contact URIs in REGISTER requests can crash  
Asterisk  
Nature of Advisory  Remote Crash  
  SusceptibilityRemote Authenticated Sessions 
 Severity   Major 
  Exploits KnownNo
   Reported On  January 19, 2016  
   Reported By  George Joseph 
Posted On   
 Last Updated OnFebruary 10, 2016 
 Advisory Contact   Mark Michelson  
 CVE Name   

Description  Asterisk may crash when processing an incoming REGISTER  
 request if that REGISTER contains a Contact header with a
 lengthy URI. 
  
 This crash will only happen for requests that pass   
 authentication. Unauthenticated REGISTER requests will not   
 result in a crash occurring. 
  
 This vulnerability only affects Asterisk when using PJSIP
 as its SIP stack. The chan_sip module does not have this 
 problem. 

Resolution  Measures have been put in place to ensure that REGISTER   
requests with long Contact URIs are rejected instead of   
causing a crash.  

   Affected Versions   
 Product   Release  
   Series   
  Asterisk Open Source  11.xUnaffected
  Asterisk Open Source  13.xAll versions  
   Certified Asterisk   11.6Unaffected
   Certified Asterisk   13.1All versions  

  Corrected In
  Product  Release
Asterisk Open Source13.8.1
 Certified Asterisk   13.1-cert5  

Patches
 SVN URL  Revision

   Links 

Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security  
  
This document may be superseded by later versions; if so, the latest  
version will be posted at 
http://downloads.digium.com/pub/security/AST-2016-004.pdf and 
http://downloads.digium.com/pub/security/AST-2016-004.html

Revision History
 Date   Editor   Revisions Made   
February 10, 2016   Mark Michelson  Initial creation  

   Asterisk Project Security Advisory - AST-2016-004
  Copyright (c) 2016 Digium, Inc. All Rights Reserved.
  Permission is hereby granted to distribute and publish this advisory in its
   original, unaltered form.


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Asterisk 13.1-cert5 and 13.8.1 Now Available (Security Release)

[Asterisk Development Team]

The Asterisk Development Team has announced security releases for Certified
Asterisk 13.1 and Asterisk 13. The available security releases are released
as
versions 13.1-cert5, and 13.8.1.

These releases are available for immediate download at
http://downloads.asterisk.org/pub/telephony/asterisk/releases

The release of these versions resolves the following security
vulnerabilities:

* AST-2016-004: Long contact URIs in REGISTER requests can crash Asterisk

  Asterisk may crash when processing an incoming REGISTER request if that
  REGISTER contains a Contact header with a lengthy URI. This crash will
only
  happen for requests that pass authentication. Unauthenticated REGISTER
  requests will not result in a crash occurring.

* AST-2016-005: TCP denial of service in PJProject

  PJProject has a limit on the number of TCP connections that it can accept.
  Furthermore, PJProject does not close TCP connections it accepts. By
default,
  this value is approximately 60. An attacker can deplete the number of
allowed
  TCP connections by opening TCP connections and sending no data to
Asterisk.

  If PJProject has been compiled in debug mode, then once the number of
allowed
  TCP connections has been depleted, the next attempted TCP connection to
  Asterisk will crash due to an assertion in PJProject. If PJProject has not
  been compiled in debug mode, then any further TCP connection attempts
will be
  rejected. This makes Asterisk unable to process TCP SIP traffic.

For a full list of changes in the current releases, please see the
ChangeLogs:

http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-certified-13.1-cert5
http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-13.8.1

The security advisories are available at:

 * http://downloads.asterisk.org/pub/security/AST-2016-004.pdf
 * http://downloads.asterisk.org/pub/security/AST-2016-005.pdf

Thank you for your continued support of Asterisk!
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] SIP port blocking

[Dovid Bender]

Darryl,

We had this with a large ISP in the US. They blamed it on a software bug. For 
this reason we offer clients the option to use a non standard port. It's most 
likely your ISP that is blocking the port for g-d knows what reason.

Regards,

Dovid

-Original Message-
From: Darryl Moore 
Sender: asterisk-users-bounces@lists.digium.comDate: Thu, 14 Apr 2016 17:48:02 
To: Asterisk Users Mailing List - Non-Commercial 
Discussion
Reply-To: Asterisk Users Mailing List - Non-Commercial Discussion
 
Subject: [asterisk-users] SIP port blocking

Hey all. This isn't directly an Asterisk question, but it is Asterisk 
related because I am using SIP on asterisk.

The last couple of days I found that our asterisk box was having all 
packets originating from port 5060 being blocked.

If I moved my SIP port to any other port I could register and place 
calls, leaving it on 5060 I can do neither. Also if I ran tcpdump on 
both ends of my truck connection. I could see all packets arriving at 
the other end ONLY when they were not originating from port 5060.

The next question was where was it being blocked. running traceroute 
yielded the following:

root@1940IronStone:~# traceroute -z 1000 -A -U -p 5060 --sport=5060 
70.xx.xx.200
traceroute to 70.xx.xx.200 (70.xx.xx.200), 30 hops max, 60 byte packets
  1  192.168.1.1 (192.168.1.1) [*]  3.837 ms  5.282 ms  6.280 ms
  2  64.230.199.2 (64.230.199.2) [AS577]  9.690 ms * *
  3  64.230.232.177 (64.230.232.177) [AS577]  24.936 ms * *
  4  agg2-toronto63_xe5-1-0.net.bell.ca (64.230.156.178) [AS577] 40.235 
ms * *
  5  lns9-toronto63_GE1-0_101.net.bell.ca (64.230.103.145) [AS577] 
10.382 ms * *
  6  * * *
  7  * * *
  8  * * *
  9  * * *

Notice the second and third packet at each hop after the first router 
all timeout. Even when I put a long delay between packets. Looking 
further, I find the same response no matter what source port I use. It 
appears any UDP packet stream from the same port is being blocked.

I don't see this behaviour if I allow traceroute to use random source 
ports for each packet, and I don't see this on other networks.


traceroute  -A -U -p 5060 70.xx.xx.200
traceroute to 70.xx.xx.200 (70.xx.xx.200), 30 hops max, 60 byte packets
  1  192.168.1.1 (192.168.1.1) [*]  62.783 ms  62.759 ms  62.743 ms
  2  64.230.199.2 (64.230.199.2) [AS577]  66.565 ms  66.550 ms 66.587 ms
  3  64.230.232.177 (64.230.232.177) [AS577]  66.488 ms  66.487 ms 66.535 ms
  4  agg2-toronto63_xe5-1-0.net.bell.ca (64.230.156.178) [AS577] 66.521 
ms  66.510 ms  66.552 ms


Has anybody seen anything like this before? I'm going to send this to 
the ISP, but I thought I'd find out if anybody else had ever run into it.


Thanks,
Darryl


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] SIP port blocking

[Darryl Moore]

Hey all. This isn't directly an Asterisk question, but it is Asterisk 
related because I am using SIP on asterisk.


The last couple of days I found that our asterisk box was having all 
packets originating from port 5060 being blocked.


If I moved my SIP port to any other port I could register and place 
calls, leaving it on 5060 I can do neither. Also if I ran tcpdump on 
both ends of my truck connection. I could see all packets arriving at 
the other end ONLY when they were not originating from port 5060.


The next question was where was it being blocked. running traceroute 
yielded the following:


root@1940IronStone:~# traceroute -z 1000 -A -U -p 5060 --sport=5060 
70.xx.xx.200

traceroute to 70.xx.xx.200 (70.xx.xx.200), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1) [*]  3.837 ms  5.282 ms  6.280 ms
 2  64.230.199.2 (64.230.199.2) [AS577]  9.690 ms * *
 3  64.230.232.177 (64.230.232.177) [AS577]  24.936 ms * *
 4  agg2-toronto63_xe5-1-0.net.bell.ca (64.230.156.178) [AS577] 40.235 
ms * *
 5  lns9-toronto63_GE1-0_101.net.bell.ca (64.230.103.145) [AS577] 
10.382 ms * *

 6  * * *
 7  * * *
 8  * * *
 9  * * *

Notice the second and third packet at each hop after the first router 
all timeout. Even when I put a long delay between packets. Looking 
further, I find the same response no matter what source port I use. It 
appears any UDP packet stream from the same port is being blocked.


I don't see this behaviour if I allow traceroute to use random source 
ports for each packet, and I don't see this on other networks.



traceroute  -A -U -p 5060 70.xx.xx.200
traceroute to 70.xx.xx.200 (70.xx.xx.200), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1) [*]  62.783 ms  62.759 ms  62.743 ms
 2  64.230.199.2 (64.230.199.2) [AS577]  66.565 ms  66.550 ms 66.587 ms
 3  64.230.232.177 (64.230.232.177) [AS577]  66.488 ms  66.487 ms 66.535 ms
 4  agg2-toronto63_xe5-1-0.net.bell.ca (64.230.156.178) [AS577] 66.521 
ms  66.510 ms  66.552 ms



Has anybody seen anything like this before? I'm going to send this to 
the ISP, but I thought I'd find out if anybody else had ever run into it.



Thanks,
Darryl


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

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

Re: [asterisk-users] recreating extensions.conf from live dialplan ?

[A J Stiles]

On Wednesday 13 Apr 2016, Jeremy Kister wrote:
> On 4/13/16 11:57 AM, A J Stiles wrote:
> > You could try
> > *CLI> dialplan show
> 
> Between my older backup and dialplan show, I guess that's my best shot.
> 
> Thanks :D

I'll have a go this lunchtime at knocking up a Perl script  {for that is my 
language of choice}  to try to recreate an extensions.conf file from the 
`dialplan show` CLI output.  All the necessary stuff seems to be there, even 
labels for GoTo statements .

-- 
AJS

Note:  Originating address only accepts e-mail from list!  If replying off-
list, change address to asterisk1list at earthshod dot co dot uk .

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Delivering Asterisk IVR data to softwares using XMPP

[Marcelo Terres]

Hello.

I developed a little project (a PoC) to "integrate" Asterisk IVRs with
"other softwares", allowing that data already entered in IVR can be used in
other stages of a customer service, for example.

The main goal is to provide more efficiency and interoperability between
different solutions in a heterogeneous enterprise scenario.

Despite the fact that I started this project to integrate Asterisk IVRs
with customer service softwares, this is a multipurpose project that can be
used with any kind of software that you want.

The project uses the Asterisk's ARI API and XMPP (PubSub) to deliver the
information.

You can find more informations (including source code for download) in my
blog at
https://www.mundoopensource.com.br/delivering-asterisk-ivr-data-to-softwares-using-xmpp/
.

Any doubts or suggestions are welcomed.

Regards,
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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