Category Archives: pbx

How to integrate Avaya Communication Manager and Session Manager 6.1 with Asterisk

As with most technical documents of this type, I wrote this because I could not find this information no matter how many Google searches I tried. There’s information about connecting Avaya Communication Manager directly with Asterisk using the H.323 channel drivers, there’s information regarding integration with the Avaya SIP Enablement Server, and I did find some information about some older versions of System Manager.

However, even the information I did see was a simple lab assignment. There was no information on actually using the new integration to do cool things. Some of you may have been tasked with integrating the Avaya PBX with Microsoft Lync. This tutorial provides a great proof-of-concept for Lync integration. We can test everything with Asterisk and it all in the telecom sandbox at your company.

This tutorial is for those of you who already have an Avaya Communication Manager and one or more Session Managers already set up – probably because you’re using Modular Messaging 6.x. Therefore, you have all the ingredients you need to add Asterisk to the mix.

Okay, so let’s assume your Communication Manager is already connected to Session Manager. Often this is the case due to the fact that Modular Messaging is now SIP based and uses Session Manager to connect to Communication Manager. I wanted to connect my Avaya Communication Manager to an Asterisk system. To do so, I need to know a few things about my existing infrastructure. You may already know these things about your PBX. If so, skim this part and skip to “Build the Route to Asterisk”

Part 1 – Confirming the current integration

So how is your Communication Manager connected to Session Manager? Let’s follow the rabbit:

First, look at the pilot number for voicemail, you’ll probably see that it’s a hunt group pilot number. Let’s say your voicemail pilot extension is 2000:

list usage extension 2000
                             LIST USAGE REPORT
Used By
Hunt Group           Group Number         5                      Group Ext

Now display that hunt group

display hunt-group 5                                            Page   2 of  60
                                  HUNT GROUP

                      Message Center: sip-adjunct

     Voice Mail Number        Voice Mail Handle         Routing Digits
                                                 (e.g., AAR/ARS Access Code)
     3992000                  sipmm-la                  801

This pilot number dials the AAR feature code, then 3992000. Now list aar:

list aar analysis                                                      Page   1
                           AAR DIGIT ANALYSIS REPORT
                            Location:  all
               Dialed            Total        Route    Call      Node
               String          Min    Max    Pattern   Type     Number
         1010                   4      4      13       aar
         14                     6      6      40       aar
         3990022                7      7      29       aar
         3992000                7      7      92       aar
         4010                   4      4      19       aar
         4099                   4      4      44       aar

And you can see that 3992000 goes to route pattern 92. Now look at route 92

display route-pattern 92                                        Page   1 of   3
                    Pattern Number: 92  Pattern Name: MM -LA
                             SCCAN? n     Secure SIP? n
    Grp FRL NPA Pfx Hop Toll No.  Inserted                             DCS/ IXC
    No          Mrk Lmt List Del  Digits                               QSIG
                             Dgts                                      Intw
 1: 91   0                    3                                         n   user
 2: 92   0                    3                                         n   user
 3: 93   0                    3                                         n   user
 4:                                                                     n   user
 5:                                                                     n   user
 6:                                                                     n   user

In my case, I have three Session Managers. I just care about the first one for now. So note that the first trunk group is 91. Now display trunk group 91:

display trunk-group 91                                          Page   1 of  21
                                TRUNK GROUP

Group Number: 91                   Group Type: sip           CDR Reports: y
  Group Name: MM SIP to LA                COR: 22       TN: 1        TAC: 815
   Direction: two-way        Outgoing Display? n
 Dial Access? n                                   Night Service:
Queue Length: 0
Service Type: tie                   Auth Code? n
                                              Member Assignment Method: auto
                                                       Signaling Group: 91
                                                     Number of Members: 96

And note that this trunk group uses signaling group 91. Now display signaling group 91:

display signaling-group 91 
                                SIGNALING GROUP

 Group Number: 299            Group Type: sip
  IMS Enabled? n        Transport Method: tls
        Q-SIP? n                                             SIP Enabled LSP? n
     IP Video? n                                   Enforce SIPS URI for SRTP? y
  Peer Detection Enabled? y  Peer Server: SM

   Near-end Node Name: procr                 Far-end Node Name: sipmm-la
 Near-end Listen Port: 5061                Far-end Listen Port: 5061
                                        Far-end Network Region: 5

Far-end Domain:
                                             Bypass If IP Threshold Exceeded? n
Incoming Dialog Loopbacks: eliminate                  RFC 3389 Comfort Noise? n
         DTMF over IP: rtp-payload            Direct IP-IP Audio Connections? y
Session Establishment Timer(min): 3                     IP Audio Hairpinning? n
         Enable Layer 3 Test? y                   Initial IP-IP Direct Media? n
H.323 Station Outgoing Direct Media? n            Alternate Route Timer(sec): 6

And note that this signaling group connects the Communication Manager main processor (procr) to a node name called sipmm-la. Now list node-names:

list node-names all                                                    Page   4

                        NODE NAMES

Type     Name              IP Address
IP       cm-oc01p
IP       default 
IP       iolan-la
IP       medpro-la1
IP       medpro-la2
IP       medpro-la3
IP       medpro-la4
IP       medpro-ny1
IP       medpro-ny2
IP       medpro-oc1
IP       medpro-oc2
IP       procr   
IP       procr6            ::
IP       sipmm-la

And note that the node name is IP address So in a nutshell, when I dial the voicemail pilot number, the call gets routed to my local session manager That’s pretty much all we needed to know from the Communication Manager point of view.

Part 2 – Building the Route to Asterisk via Session Manager

What we really want is to set up a new route with new extensions between Communication Manager and Session Manager. Next we’ll configure Session Manager to understand a new number range and route it over to Asterisk.

In the case of a single pilot number, I could duplicate the hunt group method that is already set up. However, for more flexibility, I wanted a range of numbers to route to Asterisk. Or even if I do want to point individual numbers, I don’t want to create hunt groups for each one – I just want the number to route over to Asterisk through AAR routing.

So in my case, I had a spare DID number range ending in 44xx that I wanted to send over to Asterisk. So in CM, any four-digit number starting with 44 should go to Session Manager. Note that my route pattern 92 above deletes three digits. I don’t want to delete the first three digits of my 44xx extensions, so I will create a new route pattern that points to the same 91 trunk group. In my case, I used 90:

display route-pattern 90                                        Page   1 of   3
                    Pattern Number: 90  Pattern Name: SIP to SM
                             SCCAN? n     Secure SIP? n
    Grp FRL NPA Pfx Hop Toll No.  Inserted                             DCS/ IXC
    No          Mrk Lmt List Del  Digits                               QSIG
                             Dgts                                      Intw
 1: 91   0                                                              n   use

Now I want to point an entire internal number range to this route using AAR. So the first thing I need to do is edit my uniform dial plan so CM will use AAR routing when I dial this range:

list uniform-dialplan start 41                                         Page   2
                      UNIFORM DIAL PLAN TABLE

 Matching Pattern   Len   Del   Insert Digits   Net    Conv   Node Num

 4129                4     0                    ext     n
 4152                4     0                    ext     n
 4156                4     0                    ext     n
 4163                4     0                    ext     n
 4171                4     0                    ext     n
 4232                4     0                    ext     n
 44                  4     0                    aar     n
 4541                4     0                    ext     n
 4552                4     4      2089          ext     n
 4583                4     0                    ext     n
 4596                4     0                    ext     n
 4598                4     0                    ext     n

Fortunately CM is very forgiving with aar vs. ext. If I can digress for one screenshot, note that my dialplan analysis table defines all four-digit patterns that begin with 4 as extensions. However, I am able to override this in the uniform dialplan table and point these to aar in the table entry above.

display dialplan analysis                                       Page   1 of  12
                             DIAL PLAN ANALYSIS TABLE
                                   Location: all            Percent Full: 5

    Dialed   Total  Call     Dialed   Total  Call     Dialed   Total  Call
    String   Length Type     String   Length Type     String   Length Type
   0           4   ext      37          4   ext      77          4   ext
   20          4   ext      4           4   ext      78          4   ext
   21          6   ext      5           4   ext      79          4   ext
   22          6   ext      51          6   ext      888         3   fac
   23          6   ext      64          4   ext      
   24          6   ext      65          4   ext      
   25          6   ext      66          4   ext      
   26          6   ext      67          4   ext      
   27          4   ext      72          4   ext      
   29          6   ext      73          4   ext

So back to CM routing. Now that I have defined 44xx to point to the aar table, let’s create the aar entry we need to send this to Session Manager:

list aar analysis                                                      Page   1
                           AAR DIGIT ANALYSIS REPORT
                            Location:  all
               Dialed            Total        Route    Call      Node
               String          Min    Max    Pattern   Type     Number
         1010                   4      4      1        aar
         14                     6      6      400      aar
         3990022                7      7      298      aar
         3992000                7      7      299      aar
         4010                   4      4      11       aar
         4099                   4      4      44       aar
         44                     4      4      90       aar
         63xx                   4      4      25       aar
         74                     4      4      24       aar
         750                    6      6      299      aar

Now any four digit numbers starting with 44 will route (via route pattern 90) over to my session manager. Next, we need to configure session manager to route these to Asterisk!

Part 3 – Configuring Session Manager via System Manager

Now, I don’t know your experience with System Manager, but it seems that if I turn my back for a few weeks, the Admin password stops working and I have to reset it via SSH. Hopefully you have better luck than I do.

Major Gotcha: The first time I worked on this routing in System Manager, I just couldn’t get the calls to work. They would die in Session Manager with extremely unhelpful errors. After some troubleshooting, I discovered my changes weren’t synchronizing between System Manager and Session Manager. I had to go into Home->Replication and “repair” the replica group. I have done this several times since then and all of my calls during replication route fine. I don’t think it is service-affecting (with my configuration anyway). Your results may vary. Be careful.



I’ve worked on PBXs for a long time. Naturally, it can sometimes take a while to get comfortable with the GUI or command line of new systems. System Manager was tough for me. It’s such an abstraction from the actual routing engine (Session Manager) and I don’t get a chance to use a command line. I guess web interfaces drive me crazy for that reason – they’re a front-end to the actual magic, and I like to be closer to the soul of a PBX.

Enough rant – the actual configuration all takes place within Home->Routing. I just went in order down the list on the left. First, I configured a location called “LA-Asterisk”.





Next I created an Adaptation also called LA-Asterisk. Note in the screenshot below, there is a 4-digit extension pattern defined. We will do this later.

avaya-adaptation1 avaya-adaptation-asterisk

Next, create a SIP Entity. This is where you define your Asterisk server



Next, create the Entity Link to “connect” your Asterisk and Session Manager together:



In my case, I went for simple UDP connectivity. Next I create the Routing Policy for Asterisk:



Don’t worry about dial patterns or regular expressions on this screen. Just set up a SIP Entity and Time of Day and commit.

Then the Dial Pattern:




Note in my case, the PBX is sending the full E.164 number to Session Manager. Well, this isn’t entirely accurate. To digress again, the PBX is sending the regular extension, but the Adaptation for Communication Manager defines several digit conversion rules to convert these to E.164 numbers. This allows for a very flexible system within Session Manager. As a result of this digit conversion, the internal routing of the Session Manager uses the E.164 numbers and this is what you see when you trace. Here are my Adaptation rules:



I’ve erased the DID numbers there – I’m not much of a photo editor. You can see how the various extension ranges and lengths translate into E.164. Note that four-digit non-DIDs are translated to +1000000xxxx. This is how Avaya set up this site and I assume the best practice. I work at another site (set up by an Avaya business partner) that was not normalized to E.164 and it’s been kind of a pain to manage as we’ve added DIDs and extensions.

So back to Communication Manager routing: do you remember way back when I mentioned you could use the “hunt group” routing to send calls to Asterisk? I created a hunt group in CM that looks like this:

display hunt-group 9                                            Page   1 of  60
                                  HUNT GROUP

            Group Number: 9                                ACD? n
              Group Name: Asterisk                       Queue? n
         Group Extension: 2022                          Vector? n
              Group Type: ucd-mia                Coverage Path:
                      TN: 1          Night Service Destination:
                     COR: 21                   MM Early Answer? n
           Security Code:               Local Agent Preference? n
 ISDN/SIP Caller Display: mbr-name

display hunt-group 9                                            Page   2 of  60
                                  HUNT GROUP

                      Message Center: sip-adjunct

     Voice Mail Number        Voice Mail Handle         Routing Digits
                                                 (e.g., AAR/ARS Access Code)
     3992022                  ast-la                    888

This hunt group will send calls to 2022 over to Session Manager with a dial pattern of ast-la. You can then create a regular expression in System Manager to match this pattern:

Why would you want to do this? Well, this is how the Avaya technicians originally set up the routing to Modular Messaging. I suspect it allows the SIP header to retain the original dialed number as it is passed across. There’s a “diversion” header in the SIP invite, and this is how the originally-dialed number gets to Modular Messaging. I happened to set this up in a desperate attempt to get Session Manager to route for me. When I use the traceSM utility in Session Manager, I noticed that Session Manager was not trying to find a match for this pattern. This is when I discovered that the replication wasn’t working between System Manager and Session Manager. Once I fixed the replication, the rest of the routing worked and I left this in place rather than pull it all out. More on traceSM later.

16:03:51,290 |   Dial Pattern route parameters   | URI Domain:  Location: LA-MAIN-CM
16:03:51,290 |   Dial Pattern route parameters   | URI Domain: null  Location: LA-MAIN-CM
16:03:51,290 |     Trying Dial Pattern route     | Domain: null  Location: LA-MAIN-CM
16:03:51,290 |   Dial Pattern route parameters   | URI Domain:  Location: null
16:03:51,290 |     Trying Dial Pattern route     | Domain:  Location: null
16:03:51,290 |   Dial Pattern route parameters   | URI Domain:  Location: null
16:03:51,290 |   Dial Pattern route parameters   | URI Domain: null  Location: null
16:03:51,290 |     Trying Dial Pattern route     | Domain: null  Location: null
16:03:51,290 |  Request Regular Expression rout  | for:
16:03:51,291 |  Trying Regular Expression route  | pattern: sipmm-ny.*  for: sip:ast-la@abc.corp
16:03:51,291 |  Trying Regular Expression route  | pattern: sipmm-la.*  for: sip:ast-la@abc.corp
16:03:51,291 |  Trying Regular Expression route  | pattern: sipmm-oc.*  for: sip:ast-la@abc.corp
16:03:51,291 |  Trying Regular Expression route  | pattern: ast-la.*  for: sip:ast-la@abc.corp
16:03:51,291 |  Trying Regular Expression route  | pattern: sipmm-ny.*  for:
16:03:51,291 |  Trying Regular Expression route  | pattern: sipmm-la.*  for:
16:03:51,291 |  Trying Regular Expression route  | pattern: sipmm-oc.*  for:
16:03:51,291 |  Trying Regular Expression route  | pattern: ast-la.*  for:
16:03:51,291 |     Regular Expression found      | pattern: ast-la.*  for:  RoutePolicyList
16:03:51,291 |            Route found            | for:  SIPEntity: asterisk-la01p
16:03:51,291 |         Entity Link found         | SIPEntity: asterisk-la01p  EntityLink: sip-oc1->UDP, b
16:03:51,291 |     Entity Link to another SM     | To: sip-oc1  MyInstance: sip-la1
16:03:51,291 |         Entity Link found         | SIPEntity: sip-oc1  EntityLink: sip-la1->TLS, biD
16:03:51,291 |        Request Adaptation         | Adapter: LA-MAIN-CM
16:03:51,292 |     Applied egress Adaptation     | P-Asserted-Identity="Roger Ramjet" <sip:2135552245@abc.corp 16:03:51,292 |        Routing SIP request        | SipEntity: asterisk-la1  EntityLink: sip-oc01->UDP:50
16:03:51,292 |         Entity Link found         | SIPEntity: sip-oc1  EntityLink: sip-la1->TLS, biD
16:03:51,293 |  No hostname resolution required  | Routing to: sip:;transport=tls;lr;sm-routethru
16:03:51,294 |           |--INVITE-->|           | (8) T:ast-la F:+12135552245 U:ast-la P:terminating
16:03:51,342 |           |<--Trying--|           | (8) 100 Trying
16:03:52,419 |           |

Once you create a regular expression in System Manager, you should see an attempt to match it in traceSM. I wasn’t seeing my new patterns in this “Trying…” list. If you don’t see your patterns, it may be time to repair the replication.

Part 4 – Configure Asterisk to accept inbound calls from Communication Manager

Ok, so you finally have CM configured, and you think you have Session Manager/System Manager configured. Now for the last step. In my case, I was happy to finally get to Asterisk. Getting back to my rant about Session Manager, I like Asterisk because it’s completely command line and config files. This allows you to get very close to the inner workings of Asterisk.

Asterisk was a simple two step configuration: sip.conf and extensions.conf.

Just add these lines to /etc/asterisk/sip.conf


And add these lines to /etc/asterisk/extensions.conf. Note that we’re creating a context for our Avaya Session Manager and adding it to the default context. Later you can pull this out, but for now it provides a nice way to test incoming calls by sending them to the “congratulations” demo that came with Asterisk.

exten => ast-la,1,noop
exten => ast-la,n,goto(demo,1000,1)
exten => 4498,1,goto(demo,1000,1)
exten => 4499,1,meetme(4499,1)

; By default we include the demo.  In a production system, you
; probably don't want to have the demo there.
include => demo
include => internal
include => avaya-la

So now let’s test. We should have these things in place:

  1. Connectivity between Communication Manager and Session Manager
  2. Connectivity between Session Manager and Asterisk
  3. Routes built from Communication Manager through Session Manager to Asterisk

Now when I call a 44xx extension, the Communication Manager will send it via AAR to Asterisk. Let’s look at that call within Communication Manager:

list trace station 2245                                                Page   1
                                LIST TRACE
time            data
13:12:11 TRACE STARTED 03/19/2012 CM Release String cold-00.1.510.1-19100
13:12:13     active station      2245 cid 0x11c3
13:12:13     G711MU ss:off ps:20
             rgn:1 []:11394
             rgn:1 []:59628
13:12:15 SIP>INVITE SIP/2.0
13:12:15     Call-ID: 801ecff7b275e11f7724f24def200
13:12:15     dial 4498 route:UDP|AAR
13:12:15     term trunk-group 91      cid 0x11c3
13:12:15     dial 4498 route:UDP|AAR
13:12:15     route-pattern  90 preference 1 location 1/ALL  cid 0x11c3
13:12:15     seize trunk-group 91 member 6    cid 0x11c3
13:12:15     Setup digits 4498
13:12:15     Calling Number & Name *12135552245 Roger Ramjet
13:12:15 SIP<SIP/2.0 100 Trying
13:12:15     Call-ID: 801ecff7b275e11f7724f24def200
13:12:15     Proceed trunk-group 91 member 6    cid 0x11c3
13:12:15 SIP<SIP/2.0 180 Ringing
13:12:15     Call-ID: 801ecff7b275e11f7724f24def200
13:12:15     Alert trunk-group 91 member 6    cid 0x11c3

We can see from this trace that the call to 4498 goes over route 90 to trunk group 91. Perfect. Now let’s watch Session Manager. If you haven’t had the chance, you can trace calls within Session Manager via a tool called traceSM. At first I wasn’t sure about it, but I’ve come to really like it. SSH into your session manager (the management interface, not the traffic interface) and login as ‘craft’. If you know your Avaya systems, you’ll know the default password. Then type ‘traceSM’. After a few seconds of loading the log file, you’ll be ready to trace.

If your system has a lot of traffic, you’ll probably want to filter your results. Type ‘f’ at the screen and filter by your test extension.

|Filter Usage:                                                         |
|  -u   Filter calls that contain  in          |
|                   the 'From' or 'To' field.                          |
|  -i           Filter SIP messages from/to  address.                  |
|  -c      Filter based on the SIP 'Call-ID' header field.             |
|  -g = Filter SIP header field  for value .                           |
|  -or              Use a logical OR operator instead of the implicit  |
|                   AND when using multiple filter options.            |
|  -nr              Do not display REGISTER messages.                  |
|  -ns              Do not display SUBSCRIBE/NOTIFY messages.          |
|  -no              Do not display OPTIONS messages.                   |
|  -na              Do not display SM related messages.                |
|Filter examples:                                                      |
| To display a call to/from 3035556666 and not REGISTER messages:      |
|    -u 3035556666 -nr                                                 |
| To display SIP messages from/to and                 |
|    -i "|"                                              |
|                                                                      |
|Current Filter:                                                       |
|New Filter: -u 4498                         |
|                                                                      |

Press enter and traceSM will re-process the log file. Then press ‘c’ to clear the results, then press ‘s’ to start the trace. Now when I re-dial extension 4498 and I can see the call pass through Session Manager:

13:39:33,115 |--INVITE-->|           |           | (1) T:4498 F:+12135552245 U:4498 P:terminating
13:39:33,117 |<--Trying--|           |           | (1) 100 Trying
13:39:33,118 |      Remote host is trusted       | Trusted
13:39:33,118 |        Request Adaptation         | Adapter: LA-MAIN-CM
13:39:33,119 |    Applied ingress Adaptation     |, History-Info=<>;index=1,"4498" UDP, biDirId=null:5060
13:39:33,121 |        Request Adaptation         | Adapter: LA-MAIN-CM
13:39:33,121 |     Applied egress Adaptation     | P-Asserted-Identity="Roger Ramjet" <>,;rout
13:39:33,121 |        Routing SIP request        | SipEntity: asterisk-la01p  EntityLink: sm-sip-la01p->UDP:5060
13:39:33,123 |  No hostname resolution required  | Routing to: sip:;lr;phase=terminating
13:39:33,124 |           |--INVITE-->|           | (1) T:4498 F:+12135552245 U:4498 P:terminating
13:39:33,195 |           |<--Trying--|           | (1) 100 Trying
13:39:33,209 |           |<--Ringing-|           | (1) 180 Ringing
13:39:33,211 |        Request Adaptation         | Adapter: LA-MAIN-CM
13:39:33,211 |        Request Adaptation         | Adapter: LA-MAIN-CM
13:39:33,212 |<--Ringing-|           |           | (1) 180 Ringing 13:39:34,455 |--CANCEL-->|           |           | (1)
13:39:34,455 ||           | (1)
13:39:34,496 |           ||           | (1)
13:39:34,499 |<--Request-|           |           | (1) 487 Request Terminated 13:39:34,548 |----ACK--->|           |           | (1)

You can see the SIP INVITE from Communication Manager. You can see Session Manager process it using the various rules in the routing engine, and you can see the INVITE passed along to Asterisk. You can use the arrow keys to highlight the INVITE and press enter to see the details:

|INVITE;routeinfo=0-0 SIP/2.0                              |
|Record-Route: <sip:;lr;sap=865602204*1*016asm-callprocessing | 
|.sar634103744~1332189573117~-1715763735~1>                                      |
|From: "Roger Ramjet" <>;tag=0f617ceb675e1123764f2  |
|4def200                                                                         |
|To: <>                                                     |
|Call-ID: 0f617ceb675e1124764f24def200                                           |
|CSeq: 1 INVITE                                                                  |
|Via: SIP/2.0/UDP;branch=z9hG4bKC0A8CC2608E7B337012365250     |
|Via: SIP/2.0/UDP;branch=z9hG4bKC0A8CC2608E7B337112365248     |
|Via: SIP/2.0/UDP;branch=z9hG4bKC0A8CC2608E7B337112365247     |
|Via: SIP/2.0/TLS;branch=z9hG4bK0f617ceb675e1125764f24def200-AP;ft  |
|=23826                                                                          |
|Via: SIP/2.0/TLS;branch=z9hG4bK0f617ceb675e1125764f24def200        |
|Supported: 100rel,histinfo,join,replaces,sdp-anat,timer                         |
|User-Agent:  Avaya CM/R016x.00.1.510.1 AVAYA-SM-                  |
|Contact: "Roger Ramjet" <sip:+12135552245@;transport=tls>      |
|Alert-Info: <>;avaya-cm-alert-type=internal            |
|Min-SE: 1200                                                                    |
|Record-Route: <sip:559ae004@;transport=tls;lr>                     |
|Record-Route: <sip:;transport=tls;lr>                          |
|Session-Expires: 1200;refresher=uac                                             |
|P-Charging-Vector: icid-value="AAS:5279-ce17f6001e175b6244f7622f2de"            |
|Content-Type: application/sdp                                                   |
|Content-Length: 210                                                             |
|P-Asserted-Identity: "Roger Ramjet" <>               |
|History-Info: <>;index=1,"4498" <>;index=1.1                                                              |
|Route: <sip:;lr>                                                  |
|Route: <sip:;lr;phase=terminating>                                   |
|P-AV-Transport: AP;fe=;ne=;tt=TLS;th;timer  |
|B=4                                                                             |
|P-Location: SM;origlocname="LA-MAIN-CM";termlocname="LA-Asterisk"               |
|Max-Forwards: 68                                                                |
|                                                                                |
|v=0                                                                             |
|o=- 1332189580 1 IN IP4                                            |
|s=-                                                                             |
|c=IN IP4                                                           |
|b=AS:64                                                                         |
|t=0 0                                                                           |
|a=avf:avc=n prio=n                                                              |
|a=csup:avf-v0                                                                   |
|m=audio 65044 RTP/AVP 0 127                                                     |
|a=rtpmap:0 PCMU/8000                                                            |
|a=rtpmap:127 telephone-event/8000                                               |

This confirms that your dial request to 4498 is passing through the Session Manager over to Asterisk. Now let’s look at Asterisk:

exten => 4498,1,goto(demo,1000,1)

Because our extensions.conf file contains the line above, the calls that come in should go to the Asterisk demo application. Let’s watch from the CLI when I call 4498 again:

  == Using SIP RTP CoS mark 5
    -- Executing [4498@default:1] Goto("SIP/avayaLA-00000037", "demo,1000,1") in new stack
    -- Goto (demo,1000,1)
    -- Executing [1000@demo:1] Goto("SIP/avayaLA-00000037", "default,s,1") in new stack
    -- Goto (default,s,1)
    -- Executing [s@default:1] Wait("SIP/avayaLA-00000037", "1") in new stack
    -- Executing [s@default:2] Answer("SIP/avayaLA-00000037", "") in new stack
    -- Executing [s@default:3] Set("SIP/avayaLA-00000037", "TIMEOUT(digit)=5") in new stack
    -- Digit timeout set to 5.000
    -- Executing [s@default:4] Set("SIP/avayaLA-00000037", "TIMEOUT(response)=10") in new stack
    -- Response timeout set to 10.000
    -- Executing [s@default:5] BackGround("SIP/avayaLA-00000037", "demo-congrats") in new stack
    -- <SIP/avayaWLA-00000037> Playing 'demo-congrats.slin' (language 'en')
  == Spawn extension (default, s, 5) exited non-zero on 'SIP/avayaWLA-00000037'

And if you could hear what I hear, you’d enjoy Allison Smith’s congratulations message also! We have inbound calls to Asterisk.

Part 5 – Configure Asterisk to send outbound calls to Communication Manager

This one is a little easier. To send internal calls to Avaya, just create an extension match in extensions.conf to match your internal number ranges. However, don’t forget that you are probably sending some numbers from Communication Manager to Asterisk. Be sure not to send these number ranges back to Communication Manager! In my case, Communication Manager is sending 44xx to Asterisk so I make sure I keep those numbers internal to Asterisk by dialing any registered SIP phones (more on this later).

;these are LA extensions registered through softphones
exten => _44XX,1,Dial(SIP/${EXTEN}) ; these stay internal to Asterisk
exten => _91XXXXXXXXXX,1,dial(SIP/${EXTEN}@avayaLA) ; external – leave the 9 in place
exten => _[245]XXX,1,dial(SIP/${EXTEN}@avayaLA) ; 4 digits starting with 0, 4, or 5

To test this, you can issue an ‘originate’ command right from the Asterisk CLI.

localhost*CLI> originate SIP/2245@avayaWLA extension 1000
  == Using SIP RTP CoS mark 5
    -- Executing [1000@default:1] Goto("SIP/avayaLA-00000049", "default,s,1") in new stack
    -- Goto (default,s,1)
    -- Executing [s@default:1] Wait("SIP/avayaLA-00000049", "1") in new stack
    -- Executing [s@default:2] Answer("SIP/avayaLA-00000049", "") in new stack
    -- Executing [s@default:3] Set("SIP/avayaLA-00000049", "TIMEOUT(digit)=5") in new stack
    -- Digit timeout set to 5.000
    -- Executing [s@default:4] Set("SIP/avayaLA-00000049", "TIMEOUT(response)=10") in new stack
    -- Response timeout set to 10.000
    -- Executing [s@default:5] BackGround("SIP/avayaLA-00000049", "demo-congrats") in new stack
    -- <SIP/avayaWLA-00000049> Playing 'demo-congrats.slin' (language 'en')
  == Spawn extension (default, s, 5) exited non-zero on 'SIP/avayaWLA-00000049'

The command above causes Asterisk to launch a call to 2245 through the avayaLA peer and send the call to extension 1000. You should get a call and when you answer, you’ll hear the demo. Likewise, external calls should include the ‘9’ when sent to Communication Manager. Your system will probably pass this through Session Manager to Communication Manager just fine since Modular Messaging needs to dial out sometimes (for find-me/follow-me features).

So that’s it! You now have an Avaya Communication Manager sending and receiving calls to Asterisk via Session Manager! This is a great proof-of-concept for you to start your Lync integration. I’ll write up a separate article for Lync. There’s an amazing amount of politics involved in a Lync project. I’d love to hear from you about it.

Avaya 9630 Locks / Reboots up when registering

I recently had an Avaya phone in a reboot cycle. It would boot up, then when it registered it would lock up and after a couple minutes reboot again. The display looked like it was up and running fine, but when you press the SPEAKER button I would get three beeps. This is typically what happens when a phone cannot get TCP/IP signalling traffic to the call server. And the night before we had some maintenance on that Ethernet switch so I immediately suspected a network problem.

Just in case, I did a “CLEAR” procedure on the phone. Then I swapped out the phone. Then I swapped out the patch cables (at both ends). Then I moved the phone to a different port in the Ethernet switch. No matter what I did, the phone locked up. Then I tried something I probably should have tried earlier – I logged in a different extension and it worked fine! Then I logged the “bad” extension into a different phone and it locked up!

Turns out the config file on the web server (1234_96xxdata.txt) was incomplete. Apparently it was related to the network after all! When the phone was writing its data file to the web server the previous night, the write operation was interrupted as the network guy shut off the Ethernet switch. The resulting data file was incomplete – it had about half the call log entries and a partial line at the end. But none of the important lines you’d expect in the file such as:

Edit Dialing=1
Go to Phone Screen on Calling=0
Go to Phone Screen on Ringing=1
Call Timer=1
Visual Alerting=0
History Active=1
Log Bridged Calls=1
Audio Path=1
Personalized Ring=0
Handset AGC=1
Headset AGC=1
Speaker AGC=1
Error Tone=1
Button Clicks=0
Text Size=1
Contacts Pairing=0
Voice Initiated Dialing=1
Voice Dialing Help Counter=0
Personalized Ring Menu=0
Go to Phone Screen on Answer=0
Voice Initiated Dialing Language=

If the file were missing, the phone would use default values and create the file at the next backup. However, since the file was there, the phone processed it but ended up locking up because it was incomplete. In all my years working with these phones, I’ve never seen that before. I wouldn’t have thought it possible for the phone’s interrupted “HTTP PUT” operation to result in an incomplete file on the web server, but there you go. Hopefully this helps you.

I recently went through an ordeal with a PBX resetting. It’s an Avaya system using an IPSI to connect a port network back to its host, but this situation applies to anyone out there using QOS on their MPLS network. I’ve often said that being a “phone guy” is rarely about phones anymore. Most of my work – certainly troubleshooting – involves IP networking.

So I had a PBX with one IPSI that would occasionally reset. Since there was only one IPSI, the reset would cause all cards in the port network to reset as well, which would drop all calls in progress. Now this is about the worst thing that can happen when you’re responsible for the telephones. Full system outages are easier to understand. This is a reset, calls drop, users get frustrated and re-establish their calls, then it would reset again. It was a really bad situation.

What is causing the resets? Avaya said the heartbeats were failing to the IPSI. For any of you with an IPSI-connected port network, you should occasionally look for these. SSH to your Communication Manager and cd to /var/log/ecs. Then list the log files. Assuming you’re in Feburary 2013, you would look for missed heartbeats in your ecs log with the command:

cat 2013-02*.log|grep checkSlot
:pcd(5561):MED:[[3:0] checkSlot: sanity failure (1)]
:pcd(5561):MED:[[3:0] checkSlot: sanity failure (2)]
:pcd(5561):MED:[[3:0] checkSlot: sanity failure (3)]
:pcd(5561):MED:[[3:0] checkSlot: sanity failure (4)]
:pcd(5561):MED:[[3:0] checkSlot: data received replacing sanity message; socket delay is 14 secs]

I have stripped the date/time; you’ll see those on the left. Port networks and IPSIs are zero indexed, so the messages above apply to port network 4 and IPSI number 1.

I have been told that occasional sanity failures are just a part of life. These heartbeat messages are part of the Avaya protocol, not ICMP. So if you’re missing heartbeats, it’s not because ICMP is being dropped.

However, after a certain number of sanity failures, the IPSI will reset in order to re-esablish communication. How many sanity failures? That depends upon a system parameter setting:

display system-parameters ipserver-interface

Primary Control Subnet Address:
Secondary Control Subnet Address:


Switch Identifier: A
IPSI Control of Port Networks: enabled
A-side IPSI Preference: disabled
IPSI Socket Sanity Timeout: 15

802.1p: 6
DiffServ: 46

The IPSI Socket Sanity Timeout determines how many sanity failures will cause an IPSI failover (if you have two in your port network), or a reset(!) if you only have one. The reset is the IPSI’s way of trying to re-establish communication. If you get too many sanity failures, you’ll get this message:

:pcd(5561):MED:[[3:0] checkSlot: too many sanity failures (15)]

Unfortunately, this means my CM lost connectivity to the first IPSI on port network 4. If I only have one IPSI, then the IPSI and all cards in the port network will reset. If I have a redundant IPSI, then the port network will failover and everything should be okay. In my particular case a second IPSI would not have helped me. It turns out, my MPLS carrier (who had also set up our edge routers) was policing the committed access rate. I’ll explain with more detail in my next post. The resolution was to shape the traffic rather than police it.

Recommendations to the new phone administrator

I’ve been working on telephone systems for a while. And I love my job. For the past few years, I find myself working with network administrators who have been handed the job of managing the telephone system. It makes sense – the PBX is just a big voice router, and nowadays the telephones are IP network endpoints.

But there’s more to managing a voice network than knowing the data network. I’m often asked by the new telecom admin “where should I start?” There’s a lot to know. And my biggest piece of advice is to Be the Authority. By this I mean you should be the person everyone asks about telephones. And you should usually start with the telephone and your voicemail system. The telephone is a complicated endpoint. Voicemail has a ton of features and an extremely limited user interface. For example, learn how to do the following:

  • Know how to transfer a call into voicemail without ringing the station.
  • Know how to conference two parties together. This includes two inbound calls. Also, learn the limits of conferencing. How many parties can conference together?
  • Can your users transfer calls outside the PBX (i.e. to mobile numbers)? If so, what happens if voicemail picks up at the far end. How do you pull that call back? What about when you attempt to conference rather than transfer?
  • Learn what all the feature buttons do, like park, call pickup, do-not-disturb, or any one of about 200 possible features.
  • Know how to program the speed dial buttons.
  • Keep a list of conference rooms and the speakerphone numbers handy.
  • Get to know you receptionists and find out what they need in a telephone system. They probably wish they had an accurate company directory, right? In a later post I’ll talk about how to provide this.
  • Spend time walking the floor and interacting with users. When someone calls for a simple change that can be performed remotely, go visit the user or at least give him or her a call. Try to chat about how they use the phone.
  • Learn how to create an out-of-office greeting and activate/deactivate it.
  • Learn how to leave a voicemail for someone without ringing their telephone.

The goal is to know the system well. You want people to think of you when they are trying to do something new. When you’re visiting, discreetly listen to the interaction with callers. I cannot tell you how many times I’ve heard “You’ll have to call back and ask the operator” or “His extension is 8244 but you’ll have to call back. I cannot transfer from here”. Try to help these people understand how to use the phone. Of course, some folks don’t want to hear it but some do. Be helpful. Know your telephone system. Be the Authority.

What types of questions do you get?

481 Call Does Not Exist (no local tag match)

Really? I’m the only person on the entire Internet to get this message from an Avaya Session Manager?

481 Call Does Not Exist (no local tag match)

I’m trying to integrate Avaya Aura Session Manager 6.1 with an Audiocodes MP-118. I have it working in one direction so far. If all goes as planned, I’ll get this figured out and will forget all about the cause for this error 481. Alas, I look forward to it already.

UPDATE: This turned out to be sort of an asymmetric route. In the chaos and confusion of the moment, I had Session Manager A sending calls to the Audiocodes, but the Audiocodes sending responses back to Session Manager B. Hopefully this helps someone out there.

Quick fix for Avaya MAS error Access is denied (0x80070005)

It’s not that I’m an “Avaya guy”, but it just happens to be the system I’ve been working with lately. If any of you have tried to publish a caller app on Modular Messaging and gotten the message Error in application deployment (Access is denied (0x8007005)), there’s an easy fix.

Error in application deployment

In the old version 3.1, you could deploy apps via RDP, but now in version 6.x, you’re only able to do it from a local terminal. Or, you can also RDP with the /admin switch:

mstsc /v:mymas /admin

You can then deploy apps remotely. Simple, but since I couldn’t find any quick info when I googled the error, I thought I’d post it here.