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: corp.abc.com 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 10.5.20.131 IP default 0.0.0.0 IP iolan-la 10.2.4.21 IP medpro-la1 10.2.4.22 IP medpro-la2 10.2.4.23 IP medpro-la3 10.2.4.24 IP medpro-la4 10.2.4.25 IP medpro-ny1 10.7.4.26 IP medpro-ny2 10.7.4.27 IP medpro-oc1 10.5.20.51 IP medpro-oc2 10.5.20.52 IP procr 10.2.20.20 IP procr6 :: IP sipmm-la 10.5.20.139
And note that the node name is IP address 10.5.20.139. So in a nutshell, when I dial the voicemail pilot number, the call gets routed to my local session manager 10.5.20.139. 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.
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.
--------------------------------------------------------------------------------------------------------------- cm01(.30) 192.168.204.39 SM100 --------------------------------------------------------------------------------------------------------------- 16:03:51,290 | Dial Pattern route parameters | URI Domain: abc.com 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: corp.abc.com Location: null 16:03:51,290 | Trying Dial Pattern route | Domain: corp.abc.com Location: null 16:03:51,290 | Dial Pattern route parameters | URI Domain: abc.com 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: sip:ast-la@corp.abc.com 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: ast-la@corp.abc.com 16:03:51,291 | Trying Regular Expression route | pattern: sipmm-la.* for: ast-la@corp.abc.com 16:03:51,291 | Trying Regular Expression route | pattern: sipmm-oc.* for: ast-la@corp.abc.com 16:03:51,291 | Trying Regular Expression route | pattern: ast-la.* for: ast-la@corp.abc.com 16:03:51,291 | Regular Expression found | pattern: ast-la.* for: ast-la@corp.abc.com RoutePolicyList 16:03:51,291 | Route found | for: sip:ast-la@corp.abc.com 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: 10.5.20.139;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
[avayaLA] type=peer qualify=yes fromdomain=corp.abc.com host=192.168.24.39 disallow=all allow=ulaw allow=g729 dtmfmode=rfc2833 canreinvite=yes
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.
[avaya-la] 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) [default] ; ; 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:
- Connectivity between Communication Manager and Session Manager
- Connectivity between Session Manager and Asterisk
- 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 [172.25.114.8]:11394 rgn:1 [172.25.24.124]:59628 13:12:15 SIP>INVITE sip:4498@corp.abc.com 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: | | -uFilter 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 1.1.1.1 and 2.2.2.2: | | -i "1.1.1.1|2.2.2.2" | | | |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:
--------------------------------------------------------------------------------------------------------------------------------- 172.25.204.30 172.25.14.131 SM100 --------------------------------------------------------------------------------------------------------------------------------- 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 | Request-URI=sip:+12135554498@corp.abc.com, History-Info=<sip:+12135554498@corp.abc.com>;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" <sip:2135552245@corp.abc.com>, Request-URI=sip:4498@corp.abc.com;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:172.25.4.231;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) sip:4498@corp.abc.com 13:39:34,455 || | (1) sip:4498@corp.abc.com 13:39:34,496 | || | (1) sip:4498@corp.abc.com 13:39:34,499 |<--Request-| | | (1) 487 Request Terminated 13:39:34,548 |----ACK--->| | | (1) sip:4498@corp.abc.com
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 sip:4498@corp.abc.com;routeinfo=0-0 SIP/2.0 | |Record-Route: <sip:192.168.214.8:15060;lr;sap=865602204*1*016asm-callprocessing | |.sar634103744~1332189573117~-1715763735~1> | |From: "Roger Ramjet" <sip:+12135552245@corp.abc.com>;tag=0f617ceb675e1123764f2 | |4def200 | |To: <sip:4498@corp.abc.com> | |Call-ID: 0f617ceb675e1124764f24def200 | |CSeq: 1 INVITE | |Via: SIP/2.0/UDP 192.168.24.8:15070;branch=z9hG4bKC0A8CC2608E7B337012365250 | |Via: SIP/2.0/UDP 192.168.24.8:15070;branch=z9hG4bKC0A8CC2608E7B337112365248 | |Via: SIP/2.0/UDP 192.168.24.8:15070;branch=z9hG4bKC0A8CC2608E7B337112365247 | |Via: SIP/2.0/TLS 192.168.24.9;branch=z9hG4bK0f617ceb675e1125764f24def200-AP;ft | |=23826 | |Via: SIP/2.0/TLS 172.25.24.30;branch=z9hG4bK0f617ceb675e1125764f24def200 | |Supported: 100rel,histinfo,join,replaces,sdp-anat,timer | |Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,INFO,PRACK,PUBLISH | |User-Agent: Avaya CM/R016x.00.1.510.1 AVAYA-SM-6.1.1.0.611023 | |Contact: "Roger Ramjet" <sip:+12135552245@172.25.24.30:5061;transport=tls> | |Alert-Info: <cid:internal@corp.abc.com>;avaya-cm-alert-type=internal | |Min-SE: 1200 | |Record-Route: <sip:559ae004@192.168.24.39;transport=tls;lr> | |Record-Route: <sip:172.25.24.30:5061;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" <sip:2135552245@corp.abc.com> | |History-Info: <sip:2135554498@corp.abc.com>;index=1,"4498" <sip:2135554498@corp.abc.com>;index=1.1 | |Route: <sip:192.168.204.39;lr> | |Route: <sip:172.25.4.31;lr;phase=terminating> | |P-AV-Transport: AP;fe=172.25.24.30:34534;ne=192.168.24.39:5061;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 172.25.24.30 | |s=- | |c=IN IP4 172.25.24.54 | |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:
localhost*CLI> == 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' localhost*CLI>
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).
[losangeles] ;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' localhost*CLI>
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.
Hi, i do this as a lab in my office, just i get a Not route to determine on SM, i dont know if I’s missing somthing in asterisk or in SM, can u give me a clue? The calls from CM or SM to Asterisk works great, its a sip trunk with udp tranport.
Regards
I would check for a “routing policy” between your CM and Asterisk. It needs to match a string of digits or a regular expression. I almost always match by digits (I’ve only used the regex for voicemail apps). Do you have a digit pattern defined to a routing policy?
We are doing SIP integration between Avaya and Asterisk….
facing same issue of Calls coming from Avaya (CM & SM) to Asterisk, but we cant make from Asterisk..
What setting should we check to solve this issue, im from asterisk side…need the guidance to solve this in Avaya settings..
How u solved this issues ,what changes you did..kindly let me know
Please let me know…we r at client side.
I did not register endpoints to Asterisk, but I believe I was able to call from the CLI just fine. The first step is to see if the problem is getting out of the Asterisk okay. When you debug from the CLI, is it sending an invite to Session Manager? If so, the problem could simply be session manager programming. If you do a traceSM in session manager (and show the call processing) you should see if the call is getting to SM and more importantly, if SM is routing it correctly.
Roger,
Thanks for taking the time to lay this all out. I did an early integration between Avaya and Asterisk about 7 years ago with PRI’s. Now I’m back in the Avaya world after a 5yr hiatus and am looking to use Asterisk for some special applications and save a chunk of money over using Avaya’s solutions.
Very cool Mark! Avaya CM/SM and Asterisk work fine technically, but they are at opposite ends of the spectrum culturally. There don’t seem to be many places that have Avaya (or Cisco, Siemens, Nortel, etc.) that are looking for Asterisk solutions. And vice-versa. Please let me know how it goes. O’Reilly’s “Asterisk The Definitive Guide” has a great chapter on using Asterisk for a standalone voicemail server. I would like to use it for a fax server myself. I have an old fax server that some users still love. It will eventually die and I’m not looking forward to it.
hi, i aslo do it in my lab , AVAYA SM&CM’s version is 6.3 with the newest patch, the asterisk version is 1.2,
Aslo i get a Not route to determine on SM, The calls from CM or SM to Asterisk works great, its a sip trunk with udp tranport. But if i restart the SM, the calls from Asterisk to CM work great within 30 min, after 30 min , the call failed with no route message. Any solution?
They fail in both directions after 30 min? My first thought is to check the SIP entity. In System manager, go to home->session manager->system status->SIP Entity Monitoring then click on your Asterisk entity. However, my Asterisk is currently down but the entity is showing u, so I guess that’s not a good indicator. If one side is not responding to OPTION messages, it might take it out of service but I would think it happens within a few minutes, not 30. If you check Home->Routing->SIP Entities and look a the detail for your Asterisk, what is the value for SIP Link Monitoring? If you change this to “link monitoring disabled” will it last longer than 30 min?
check your sm domain and cm domain setting
QJ – I believe the issue you are experiencing is due to the session refresh interval timer. There is a setting, under Asterisk SIP Settings, that will allow you to increase that value. In my CM, I have that set to 1200, I matched it to be the same on Asterisk, although I doubt the two play nice with this feature. You might as well turn it up as high as possible.
Hi, I also experienced similar issue when integrating AVAYA-SBC-Lync scenario. Its because one field in SMGR was set to 1800 s means 30 mins. I consulted AVAYA and they recommended to change that value to 0000 and everything is working fine since then.
no entity route is caused by the domain ,please check your domain. after configure domain will resolve
We are doing SIP integration between Avaya and Asterisk….
facing same issue of Calls coming from Avaya (CM & SM) to Asterisk, but we cant make from Asterisk..
What setting should we check to solve this issue, im from asterisk side…need the guidance to solve this in Avaya settings..
Please let me know…we r at client side.
from
quresh
Brilliant guide for those looking at integrating a Avaya SIP trunk to any Asterisk based platform. Thank You Roger.
My pleasure CJ. Thank you for the kind words.
I set up similar configuration with direct rtp enabled on CM and Asterisk. If you hold/transfer/conference the call you have oneway audio in my case.
If you list trace the station, you should see the UDP port that it’s trying to use for audio. These may be mismatched between the network region and asterisk. The /etc/asterisk/rtp.conf file contains the start and end ports. These should match the ip-network-region of the Asterisk. I’m sorry about your troubles. I had a similar problem between the CM and MAS when calls would leave a caller application, ring a station, then go back to a mailbox I would get one-way audio. I never could figure it out and eventually used vectors instead of the caller app. One way audio is a pain. Please let me know what you find.
You don’t need to apologize, I setup this configuration not for your guide.
ip-network-region and rtp.conf are the same
and sip phone connected to asterisk have same rtp ports range
I dump sip messages in 3 points – SM, asterisk and sip phone on my pc and make call from sip phone connected to asterisk to h.323 phone behind tha CM.
canreinvite=yes
Direct IP-IP Audio Connections? y
IP Audio Hairpinning? n
Initial IP-IP Direct Media? y
H.323 Station Outgoing Direct Media? y
After the call was established, there is no problem with it. In trace I see that rtp traffic go directly between sip phone and h.323 phone. When I press HOLD on h.323 – avaya start sending rtp from medpro to sip phone, and sip phone still sending rtp to h.323. After I go back to to call-appr, CM send reinvite without SDP, asterisk reply 200 ok with SDP and send reinvite to sip phone with previouse avaya sdp (medpro). Ater it avaya send ACK to 200 ok with SDP (c=) but it’s too late. In this situation sip phone send rtp to medpro and h.323 send rtp to sip phone. This cause oneway audio.
I google some ingo about that https://andrewjprokop.wordpress.com/2014/04/16/sip-media-management-early-offer-vs-late-offer/. It knows as late offer (sdp in ack). To work it well I need to force avaya use early offer or asterisk use late offer, but i don’t know how. In CM 6.3 in signaling-group settings not presented Direct IP-IP Early Media (a lot of references in internet). I think it can fix this ptoblem.
Off the top of my head, I don’t know how to do it either, but your mention of no SDP in the re-invite reminded me of a problem I had between the Avaya SBC-E and a Cisco CUBE. Because there was no SDP in the re-invite, we were getting one-way audio 100{0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0} of the time. Tracing back, the CM wasn’t putting SDP in the re-invite and of course the SM and SBC were passing it through that way. The fix turned out to be a delayed SDP handling in the SBC-E. That fixed it. The SBC would then re-send the SDP in the re-invite and it made the CUBE happy. Do you have an SBC? It might seem crazy, but can you build the trunks to Asterisk through the SBC? Whatever SBC you have might be able to handle the delayed SDP. I can post screenshots if you have an Avaya SBC-E. But I’m using Asterisk built straight to my SM without any issues.
Hi Roger. I have an SBC and the calls are neing dropped after holding them due to CM not sending SDP in re-invite. How did you managed to put the SDP in SBC messages? Did you made it by using scripts?
Yes! There is a setting for either “SDP Handling” or “Delayed SDP Handling”. I’ll find it. In my case, it was causing one-way audio only with Cisco CUBEs on the AT&T IPFlex network with me. I do remember I had to upgrade to get it to work. I’ll get you a screenshot and the version number…
Oh wait – in my case it was an SBC setting. But maybe you don’t have the same SBC. I was NOT able to fix it in CM.
Well, I’m using an ASBCE 7.0, which is similar to 6.3. I tried to enable “Delayed SDP Handling” with no results.
CM is sending ACK and BYE immediatly after receiving 200OK
That’s different than my issue. I also enabled “re-invite handling”. In my case the SDP wasn’t in the re-invite. I don’t know why CM would send BYE immediately. Is this for every call? I was using AT&T and it was only in specific situations (Cisco CUBEs) with other on-net AT&T customers. Is your CM hanging up for every call?
Yes, it happens in every call, no matter is incoming or outgoing.
CM does not send SDP in re-invite but expects to receive it in 200OK.
Just to clarify – CM expects SDP in the 200 OK response and if it’s not there, then it will send a BYE? If this is true, I wonder if there’s a system param in CM. If I have this right, then I’ll ask around.
That’s my conclusion since I tested the same scenario but for internal calls and SIP calls against an IPO. in all cases CM sends re-invite with no SDP and receives a 200OK with SDP, hold works fine, MOH is heard and retrieve works as well. The issue is related to calls through SBC only. That’s the reason why I say that CM is expecting an SDP within 200OK message and then replays back with an ACK that contains it’s own SDP.
Hi Roger
I am having some issues routing local calls to SM and the out to the PSTN
I’m sorry to hear it. So calls are going TO the Session Manager okay? And from there the calls are not completing? If that’s the case, are you familiar enough with traceSM to troubleshoot with that? When you start a traceSM, you can choose to see the routing logic debug as well. Let me know if we should start there, or if you’ve already checked that.
Roger,
Huge fan of the blog. It’s amazing! I am having a session manager asterisk issue and I was hoping you might have some insights.
Asterisk: 13.7.2
FreePBX: 13.0.188.9
Session Manager 7
I have my FreePBX appliance connected to my Avaya Session manager via SIP as a trunk for outgoing call processing. It works great, except I have had two incidents over ~8 days (thousands of calls in between) where the connection shows as “OK” on the Asterisk side, but not connected on the Avaya Session Manager side. Almost like my 5060 port is closing and I need to reboot FreePBX to resolve the issue (losing pending and active calls).
In my forum crawling, I noticed people indicating that the issue could be an issue with qualify and the default of 60 seconds being too long. Below is a copy of my trunk outgoing SIP settings:
host=xx.xx.xx.xxx
type=peer
nat=yes
qualify=25000
qualifyfreq=25
keepalive=25
context=from-pstn-e164-us
It’s pretty basic. Does this look correct? Is anything missing?
The last question I had was if there was a way to have the asterisk trunk status have a more accurate reflection of what is going on (versus just showing as “OK”)?
Thanks for your time and any guidance you can provide.
I also have a webpage running off the server displaying the following commands. They are used by 3-4 people simultaneously to keep an eye on things without having to be logged into the terminal. When they are on the page, it refreshes every 30 seconds.
$(ps axo pid,lstart,etime,cmd|grep -v queue|egrep ‘callbac[k]|PI[D]’)
$(( $(ps axo pid,etime,cmd|grep -v queue|egrep ‘callbac[k]|PI[D]’|wc -l) – 1 ))
$(asterisk -rx “sip show peer AVAYA-1” | grep Status)
$(free | awk ‘/Mem/{printf(“used: {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}.2f{0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}”), $3/$2*100} /buffers\/cache/{printf(“, buffers: {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}.2f{0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}”), $4/($3+$4)100} /Swap/{printf(“, swap: {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}.2f{0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}”), $3/$2100}’)
$(uptime | awk -F'[a-z]:’ ‘{ print $2}’)
$(df -h)
$(w)
Wow, that’s REALLY nice of you, Mr. Comtech!
I have not noticed any trouble with the integration, but I don’t have much traffic between them – nothing like yours. My sip.conf looks like this:
[avayaLASM]
type=peer
qualify=yes
fromdomain=ares.corp
host=10.89.32.91
disallow=all
allow=ulaw
allow=g729
dtmfmode=rfc2833
canreinvite=yes
insecure=invite,port
context=avaya
And thanks for that little tip on getting trunk status. I don’t do anything like that. I do have a little nodejs script that pushes AMI events to a collector web page, but it’s for a whole different application and is a pain to set up. I do most of my stuff in perl, php, and nodejs. I wish I knew bash a bit more. Anyway, nodejs and AMI would give you packets sent, received, and lost in real time. Send me a note at roger (at) RogerThePhoneGuy.com if you’d like more info on that. And thanks again for the kind words!
We have an Avaya Aura with Asterisk Voicemail. When one of our stations does not get answered the coverage path sends the call to Asterisk. Unfortunately, the call gets dropped as the main voicemail number appears not to be configured in Asterisk. This is the output at the CLI
NOTICE[17704][C-000001ba]: chan_sip.c:25791 handle_request_invite: Call from ‘avaya’ (X.X.X.X:13421) to extension ‘44444’ rejected because extension not found in context ‘office_vm’.
A previous Administer here configured Asterisk. He is gone and unfortunately I am new to Asterisk. Can you please help point me in the right direction to locate where the main voicemail phone number needs to be configured in Asterisk? I have looked through the voicemail.conf, extensions.conf and sip.conf and I don’t see any entry for 44444.
Thanks
I used this as my guide during the integration. Unfortunately, there is no audio during testing. What could be the issue? we already opened all ports but i dont think the RTP is going through.
Hey MJ, did you get this figured out? Sorry for the delay.