Soporte & Consultoria

Soporte Remoto y Consultoria skype : ambiorixg12.
Nota no se brinda ningun tipo de consulta o soporte fuera del blog de forma gratuita

domingo, 23 de diciembre de 2018



Depending on the size of your system and your configuration, Asterisk can consume a large number of file descriptors. In UNIX, file descriptors are used for more than just files on disk. File descriptors are also used for handling network communication (e.g. SIP, IAX2, or H.323 calls) and hardware access (e.g. analog and digital trunk hardware). Asterisk accesses many on-disk files for everything from configuration information to voicemail storage.
Most systems limit the number of file descriptors that Asterisk can have open at one time. This can limit the number of simultaneous calls that your system can handle. For example, if the limit is set at 1024 (a common default value) Asterisk can handle approximately 150 SIP calls simultaneously. To change the number of file descriptors follow the instructions for your system below:


If your system uses PAM (Pluggable Authentication Modules) edit /etc/security/limits.conf. Add these lines to the bottom of the file:
root            soft    nofile          4096
root            hard    nofile          8196
asterisk        soft    nofile          4096
asterisk        hard    nofile          8196
(adjust the numbers to taste). You may need to reboot the system for these changes to take effect.


If there are no instructions specifically adapted to your system above you can try adding the command ulimit -n 8192 to the script that starts Asterisk.


See the doc directory for more documentation on various features. Again, please read all the configuration samples that include documentation on the configuration options.
Finally, you may wish to visit the support site and join the mailing list if you're interested in getting more information.
Welcome to the growing worldwide community of Asterisk users!
        Mark Spencer, and the development community

sábado, 22 de diciembre de 2018

The WWW-Authenticate header

The WWW-Authenticate header consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. More...

An analysis of SIP Digest Authentication used in the SIP Registration Method

SIP authentication model based on the HTTP digest authentication described in the RFC 2617

This post is intended to be a neutral in its analysis of the vendors SIP registration process and the various vendors registration responses as analyzed in wire shark using the Conterpath free X lite soft phone. I have to admit that I am not very neutral about Counter path products I think there SIP soft phones are the best to benchmark other SIP phones.
I registered the X lite phone to a Cisco ISR gateway that is enabled as sip registrar, an Avaya Session Manager and for more comparisons a lab Cisco Call Manager and a version 5 Nortel NRS. The IP addresses used in these labs have been changed so that there is no possibility if revealing any proprietary information. You may also noticed paste overs on some of the screenshots, this also to avoid revealing any proprietary information.

You will see how Digest Access Authentication is used the SIP account password will be sent encrypted (normally as md5 hash of the password and some other values) and not sent in clear text.

Two types of SIP authentication that uses Digest authorization with MD5

  • Registration method
When a SIP User Agent sends Registration Request to SIP Registrar Server it will respond with a 401 Unauthorized with a challenge to provide credentials.
  • Proxy Authentication of outbound calls (which I will cover in another post)
When a SIP User Agent sends an Invite to a SIP server that will proxy the invite to a SIP Gateway, the SIP server will send back 407 Proxy Authentication Required
A RFC compliant SIP User-Agent will either: 1) Send ACK response to the server response to close the transaction. Or 2) Repeat the initial request and provide additional Authorization (for 401) or Proxy-Authorization (for 407) header in this message. This request must be sent with the same Call-ID and To, From headers as the original one and the CSeq (Command Seq) value must be incremented as seen in the wire shark trace below: SIP-reg-call-id-to-from-headers

 SIP Authentication Headers

The “WWW-Authenticate” header
  • Used by SIP Registrar Server this header is in the 401 unauthorized challenge for credentials from the User-Agent when the User Agent has made a request for registration
The “Proxy-Authenticate” header( will talk about this in another post)
  • Used typically when Proxy server is sending request to a gateway that has access to the PSTN network. But it is any call that goes over a SIP trunk to another PBX, Registrar Server that an endpoint exists.

SIP Server (User Agent Server) Challenge Strings

Here is a challenge string taken from a wire shark trace of a Xlite phone registering to a Cisco Gateway:   Cisco_gateway_reg_challenge  Server: Cisco-SIPGateway/IOS-15.2.4.M4 WWW-Authenticate: Digest realm=””,nonce=”1ADF55F80288CBA4″,algorithm=MD5,qop=”auth”

Here is the analysis of the string which is color coded to match color of text in string:

Challenge type used by the SIP Registrar server is: “WWW-Authenticate” Indicator of Authentication Scheme which is “Digest” Realm is the Protection Domain/or what I call the Dialing Domain ( in this string that I captured from a phone registered to a Cisco gateway no realm was configured) Nonce(Number Once) that can only be used one time. Every 401/407 challenge will contain a unique Nonce which means any data encrypted with it as only good for a single transaction.  Those encrypted credentials become completely worthless after a single use. Hash algorithm (which is MD5qopIndicates what “quality of protection” the client has applied to the message. Typically it is always”auth” or “auth-int”

Challenge from Avaya Session Manager Server: AVAYA-SM-

Now the Avaya Session Manager string has a few more items in its Challenge string

As with the Cisco Gateway challenge string type is “WWW-Authenticate”  This time the realm is defined as it is required in Avaya Session Manager and the realm is A new option in the string is opaque=”1234567890abcedef” I find that neither the Cisco Gateway (ISR router) or Cisco Call Manager use the opaque option.
A second new option is “stale” notice in the Avaya SM capture that it is set to true. Typically if the “stale” element is in the string the value will be false. Hold the thought on this will explain why it is set to true in the next section “User Agent Client Response to challenge” opaque A string of data, specified by the server, which should be returned by the client unchanged.( This an extra mechanism that rogue phone would not know when it tried hack the call in progress). The opaque actually makes no sense to me as all Avaya Session Manager captures I have looked at it is always “1234567890abcedef” Stale is either True or false This used to for Server to track when client tries to re-use a Nonce which happens when endpoint Re-registers.
When I tested an old Nortel NRS version 5 it also has an opaque and stale WWW-Authenticate: Digest realm=””, nonce=”3f3b346de1b216b59b05daaec5b4b603″, opaque=”62bf8eaf6c0d967565423c4e47a39a8f”, stale=false, algorithm=MD5, qop=”auth”

User Agent Client Response to challenge

Xlite phone response to the challenge from the Cisco SIP gateway

Digest username=”4427″,realm=””,nonce=”63110EC902893319″,uri=”sip:″,response=”c50963fa128e8db5069e262f176292fe”, cnonce=”a36f404a118bce981fe948ff26be22d4″,nc=00000001, qop=auth,algorithm=MD5 In second Registration request from the User Agent Client (Xlite SIP phone) is the response to the SIP server challenge the: the realm and Nonce are repeated back, then the following new values are added:
  • username is provided
  • The SIP URI is supplied
  • Response contains the encrypted password
  • CNONCE (Client NONCE) UAC supplied Nonce to effect final hash algorithm

Xlite phone response to Challenge from Avaya Session Manager User-Agent: X-Lite release 4.5.5  stamp 71236 Avaya SM xlite reg response  The

Xlite response to the Avaya SM challenge has additional component in the string: NC this is the NONCE count of requests sent by the client and supposedly must be present if qop is present. The nonce-count is used to avoid reply-attacks.

Now to my earlier observation looking at the wireshark snippets below “A second new option is “stale” notice in the Avaya SM capture that it is set to true. ”
WWW-Authenticate: Digest realm=””,qop=”auth”,opaque=”1234567890abcedef”,nonce=”145f5ca9aac6f0b9f93433188d446ae0d9f91a6ff80″,algorithm=MD5,stale=trueIn this snippet from the wire shark trace we see the Xlite phone (line number 25 and source is initiating a registration attempt with nonce that had been used in a previous registration attempt to Session Manager (destination), notice it is also sending a  nc=00000002. This indicates that nonce is being more than one time. Now on line 26 Session Manager responds with a new challenge, notice the nonce value and the stale flag being “true” On line 27 we see that Xlite phone responds to the WWW-authenticate challenge by providing the credentials with the new nonce

Wire Shark Summary of SIP registration


miércoles, 19 de diciembre de 2018

martes, 18 de diciembre de 2018

option request log

<--- Transmitting SIP request (462 bytes) to UDP: --->
Via: SIP/2.0/UDP;rport;branch=z9hG4bKPj6280c4e9-e1e3-4231-9690-757d3902a9d3
From: <sip:twilio@>;tag=7d6268d8-ac8c-44e4-aa9c-83a30558c19c
To: <>
Contact: <sip:twilio@>
Call-ID: 70d477f6-c823-4293-8b95-91deff2c7030
CSeq: 48289 OPTIONS
Max-Forwards: 70
User-Agent: Asterisk PBX 16.1.0
Content-Length:  0

<--- Received SIP response (417 bytes) from UDP: --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP;received=;rport=35921;branch=z9hG4bKPj6280c4e9-e1e3-4231-9690-757d3902a9d3
From: <sip:twilio@>;tag=7d6268d8-ac8c-44e4-aa9c-83a30558c19c
To: <>;tag=51026399c684defae5dc2ecd5fc38069.b474
Call-ID: 70d477f6-c823-4293-8b95-91deff2c7030
CSeq: 48289 OPTIONS
Server: Twilio Gateway
Content-Length: 0

lunes, 17 de diciembre de 2018

sip BYE

BYE sip: SIP/2.0
Via: SIP/2.0/UDP;rport;branch=z9hG4bKPja4d691b6-4605-459d-bc88-ca811b33084a
From: "Ambiorix" <sip:18095608344@>;tag=f14b225b-58b4-48de-8254-78d939e6141b
To: <>;tag=18426641_6772d868_e74bb600-520d-46de-ad77-822985dec5dc
Call-ID: 9834c53d-54a3-497f-92d5-f9ae0f94bf2d
CSeq: 15065 BYE
Route: <sip:;lr;ftag=f14b225b-58b4-48de-8254-78d939e6141b>
Reason: Q.850;cause=16
Max-Forwards: 70
User-Agent: Asterisk PBX 16.0.0
Content-Length:  0

  == Spawn extension (internal, 913052362323, 3) exited non-zero on 'PJSIP/6005-00000034'
  == MixMonitor close filestream (mixed)
  == End MixMonitor Recording PJSIP/6005-00000034
<--- Received SIP response (497 bytes) from UDP: --->
SIP/2.0 200 OK
CSeq: 15065 BYE
Call-ID: 9834c53d-54a3-497f-92d5-f9ae0f94bf2d
From: "Ambiorix" <sip:18095608344@>;tag=f14b225b-58b4-48de-8254-78d939e6141b
To: <>;tag=18426641_6772d868_e74bb600-520d-46de-ad77-822985dec5dc
Via: SIP/2.0/UDP;received=;rport=5066;branch=z9hG4bKPja4d691b6-4605-459d-bc88-ca811b33084a
Server: Twilio
X-Twilio-CallSid: CA877bfb05ce4cdc1ed4f3a0a75b3bc88e
Content-Length: 0

BYE sip:400@ SIP/2.0
Via: SIP/2.0/UDP;rport;branch=z9hG4bKPj1a4a1ccf-23d4-4f99-9ffb-d5fc361702b7
From: "Ambiorix" <sip:6005@>;tag=d3dc3eff-b697-4896-aff6-6be9217181e1
To: <sip:8095445555@>;tag=2ea088a078906330
Call-ID: 38005182-8b9d-469d-8703-0ec651cf0b30
CSeq: 26006 BYE
Reason: Q.850;cause=16
Max-Forwards: 70
User-Agent: Asterisk PBX 16.0.0
Content-Length:  0

  == Spawn extension (internal, 8095445555, 2) exited non-zero on 'PJSIP/6005-00000036'
  == MixMonitor close filestream (mixed)
  == End MixMonitor Recording PJSIP/6005-00000036
<--- Received SIP response (702 bytes) from UDP: --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP;rport;branch=z9hG4bKPj1a4a1ccf-23d4-4f99-9ffb-d5fc361702b7
From: "Ambiorix" <sip:6005@>;tag=d3dc3eff-b697-4896-aff6-6be9217181e1
To: <sip:8095445555@>;tag=2ea088a078906330
Call-ID: 38005182-8b9d-469d-8703-0ec651cf0b30
CSeq: 26006 BYE
User-Agent: Grandstream GXW4104 (HW 1.0, Ch:1)
Session-Expires: 180;refresher=uac
Min-SE: 180
Require: timer
Warning: 399 "detected NAT type is port restricted cone"
Contact: <sip:400@;transport=udp>
Supported: replaces, timer, 100rel, pat

viernes, 7 de diciembre de 2018

Asterisk realtime centos 7

sudo yum install epel-release
Install dependencies
yum install unixODBC-devel
yum install unixODBC
yum install python-devel
yum install python-pip
yum install MySQL-python

yum install unixODBC unixODBC-devel libtool-ltdl libtool-ltdl-devel
yum install mysql-connector-odbc



Install php 7.2

Real time

miércoles, 5 de diciembre de 2018

Asterisk 16 installation on Centos 7

   2  sestatus
   3   yum -y update

    4   yum -y groupinstall core base "Development Tools"

    5  yum install -y make wget openssl-devel ncurses-devel  newt-devel libxml2-devel kernel-devel gcc gcc-c++ sqlite-devel

    6  cd /usr/src/
    7  wget
   8  tar zxvf asterisk*
   9   cd /usr/src/asterisk*

   contrib/scripts/install_prereq install

   10  ./configure --libdir=/usr/lib64 --with-pjproject-bundled --with-jansson-bundled && make menuselect && make && make install

   11  make samples
   12  make config
   13  ldconfig
   14  service asterisk start
   15  asterisk -rvvvvvvvvvvvvv