A Technical Integration Guide for

A Technical Integration Guide for:
• AudioCodes Mediant 800 / 1000 E-SBC
• AudioCodes MediaPack Analog Gateways
in Lync/Skype for Business On-Premises
Enterprise Voice Architecture
© Copyright 2015 by Mirazon / Mirazon.com
All rights reserved

Content
Contents......................................................................................................................................................................... 2
Document Purpose...................................................................................................................................................... 3
Tested Architecture...................................................................................................................................................... 3
Initial Setup – The SBC Wizard and “standard options”...................................................................................... 4
FXO Ports – Inbound and Outbound on Mediant E-SBC..................................................................................21
FXS Ports – Integrating with Lync/Skype and ITSP and E-SBC.........................................................................31
MediaPack – Integrating with Lync/Skype and ITSP and E-SBC......................................................................38
Intra-E-SBC Routing – FXS FXO & FXO FXS.............................................................................................63
Failover (Alternate) Routing on E-SBC with Manipulation.................................................................................76
Technical Guide – Usage and Licensing Terms...................................................................................................86
“Mirazon has improved our IT by not only being a fresh set of eyes to look at a
problem but also the engineeers that work there are just a knowledge vault and they
know their stuff. Every single guy at Mirazon that I’ve talked to is an A-team player and
because of that, they can solve issues quickly and completely in a manner
that those issues don’t have to get revisited.”
– Dave Mast, NewPointe Community Church
www.mirazon.com

Document Purpose
The following document provides technical guidance to properly configure an existing on-premises
Lync or Skype for Business environment with on-premises AudioCodes gear. This document was
born out of an internal project to document our own “best practices” around enterprise voice
integration in a Microsoft Unified Communications (UC) practice.
For the purposes of this document – the basic architecture looks like this simple diagram:
In this guide, we are going to start with a simplified SIP-only configuration and add more and more
features. Over the course of this document, we’ll build upon earlier sections until we have a fully
integrated environment using all of the features discussed.
As with previously published technical guides, the ‘meat’ is the more important part of this guide.
Some screenshots are well annotated. Some are just images without any notes above or below.
Tested Architecture
The following products have been tested using the instructions in this document:
• AudioCodes Mediant 800 & 1000 E-SBC – Firmware version 6.8 with SBC Application enabled
• SIP/TLS with Microsoft UC – Lync 2013 or Skype for Business 2015
3
www.mirazon.com

• SIP/TLS with Microsoft UC – Lync 2013 or Skype for Business 2015
• SIP/TCP with Intelepeer.com – Microsoft qualified ITSP
• FXS ports inbound and outbound
• FXO ports inbound and outbound
• AudioCodes Mediapack MP112, 114, 118, 124D – Firmware version 6.6 / MP112 examples
• Lync Server 2013 – On-Premises Enterprise Voice Architecture
• Skype for Business Server 2015 – On-Premises Enterprise Voice Architecture
• Other versions (hardware and firmware) of the above may work, but, have not been tested with
these procedures.
Initial Setup – The SBC Wizard and “standard options”
When you first provision an AudioCodes SBC you will most likely utilize TLS and certificates between
the SBC and Lync/Skype. That’s not a requirement, but it’s common.
So at setup, you’ll set the IP address info and then get SSL certs (and intermediates) imported.
That’s an important first step. That is outside the scope of this guide. Follow the AudioCodes
documentation and come back. For us, we start with a simple LAN interface with IP 10.0.99.240
as below.
Now, use the SBC Wizard to set up Lync/Skype with Intelepeer. This is our baseline here. Did you
know there was an SBC Wizard? It’s available to AudioCodes Partners.
4
www.mirazon.com

www.mirazon.com
5

www.mirazon.com
6

www.mirazon.com
7

Two things of note above: VLAN 255 and no default Gateway.
You have to tag VLANs. You need to be nice to your network admins. The default admin IP (in our
case, 10.0.9.240) can be untagged. If you do 2x network interfaces (or more) you have to tag VLANs
on all subsequent networks. For this guide, I have this second interface plugged into a device that
has an interface tagged with VLAN 255. If you don’t properly tag VLANs, then you won’t get proper IP
connectivity, and things won’t work.
I also only set a default gateway on our LAN (internal) network. That means we’ll need static routes
pointing to the ITSP Intelepeer (68.68.112.0 / 20 in our case) out the WAN interface.
8
www.mirazon.com

TLS with SRTP – that’s correct for us. That’s what MOST people will do -- secure between SBC and
Lync/Skype. Sometimes you won’t have that, so you’ll have to set this as TCP / RTP and then there are
subsequent changes related to Media Security (which will be discussed below).
9
www.mirazon.com

This is Intelepeer: TCP SIP with RTP. Yes, we COULD do SRTP and that’s something we would negotiate
with Intelepeer. We typically do not though.
If we used a SIP vendor that requires UA (user authentication) – the bottom part is where you’d
set that.
10
www.mirazon.com

Just set some standard/default manipulation rules.
At Mirazon, we only send 10 (or 11) digits to the SBC. We don’t send E.164 (including the +). Some
customers will. It depends on if we use a tool like Lync Optimizer, or come in to an already existing
setup. Be mindful using Lync/Skype logging and Syslogging tools with your SBC to see what digits are
in the INVITE so you know what you need to potentially strip or add.
11
www.mirazon.com

www.mirazon.com
12

You can save this file now if you’d like, or you can download it from the Device after it reloads.
Your choice. Clicking Load to Device will upload this, and reset/reboot the device using this new
configuration.
13
www.mirazon.com

Here are a few things that we typically do next as relatively standard options.
First, let’s look at Media Security and then verify that for both Lync/Skype it’s enabled and for
Intelepeer aaand… it’s disabled. Again, as briefly discussed above, if we negotiated SRTP with
Intelepeer then we would want this enabled.
14
www.mirazon.com

If you set this to globally disabled, it requires a reboot. Don’t do this if you do TLS/SRTP for Lync.
Anything with that little yellow/lightning bolt: if you change that setting, you must reboot.
Just for completeness, here’s what this looks like for our Lync/Skype and Intelepeer IP Profiles.
Lync/Skype – Media Security – Preferable
15
www.mirazon.com

Intelepeer – set Media Security to Disable.
Make sure you have both U-law and A-law selected in the default table.
16
www.mirazon.com

Change both RFC 2833 TX and RX Payload type to 101 – default is 96.
Change default SIP General Parameter transport type to TCP. This would also be a good time to verify
your ports – maybe tcp/5060 or tcp/5068 or tls/5067 etc.
17
www.mirazon.com

Don’t forget the Static Route pointing to Intelepeer – 68.68.112.0 / 20 out our WAN interface.
Now, burn to take all of that in effect. For good measure, reboot. Wait. Log back in.
Our new architecture has more detail now.
Enable Syslog
18
www.mirazon.com

Now bring up Audiocodes Syslog and watch…
Looks good for an outbound call!
We called from my phone, 502-400-1975, to a remote phone, 502-751-2108, and the call was
successful. We can see Lync/Skype sent this to the device as TLS as expected as well.
Now, let’s test inbound.
19
www.mirazon.com

Yup, that looks good too!
We called from a remote phone, 502-751-2108, to a local phone, 502-400-1975, and the call was
successful. We can see Intelepeer connects to this device as TCP as expected as well.
When you get to a good steady state, save the .INI file.
20
www.mirazon.com

FXO Ports – Inbound and Outbound on Mediant E-SBC
Okay, so, we’ve made a good start. We have known-good working config with Lync/Skype and a
public ITSP. Let’s add some FXO Ports to the mix. What if we wanted to do an outbound 911 call and
have that use FXO by default or a backup route?
First of all, we need an FXO port. In our case, I unplugged a standard analog POTS line from an office
fax machine and plugged that cable directly into our AudioCodes FXO port 1.
See how port 1 is gray now instead of red? That means the Mediant SBC knows there’s a line there.
Now, let’s start making some changes to use this. Set FXO as One Stage and also enable Disconnect
on Dial Tone as an option.
Also, set the Current Disconnect option to Enable.
21
www.mirazon.com

Now we want to make a Hunt Group – FXO 1 – Channel 1 – Trunk Group 1
Make sure the Hunt Group Settings look right for our use-case, Cyclic Ascending. It’s only a single
port, but this allows us to increase the # of FXO ports in the previous area and things work as
expected.
Now, want to make sure Lync/Skype can actually 911 and it go out the FXO port and not the SIP Trunk.
22
www.mirazon.com

By default in our SBC Application, we have just a single outbound route… from 1 to 2 (Lync/Skype to
Intelepeer) and then vice versa. Route entry 0 is only for SIP OPTIONS (keep alive).
So, let’s make this look the way we want. We want to insert a rule ahead of Route Index 1.
23
www.mirazon.com

We are routing here from SBC IP Group 1 – Lync/Skype – and the destination is the Gateway itself.
Make sense? The FXO Port is on the “Gateway”; the SBC Application is what does routing when the
source is an IP. It will all come together soon.
Since we’re routing this to the Gateway itself on TCP / 5060, we need to make sure the SIP Interface for
the Gateway is listening on TCP, which it isn’t by default. We only enabled TLS through the SBC Wizard,
remember?
This of course precludes that we’re listening now on TCP, which we weren’t based on our initial setup.
24
www.mirazon.com

Create SIP Server Tables – the “host” matches the Office 365 IP Gateway Forwarding Address
Making more sense? We are doing SBC Routing, from Lync/Skype to the Gateway.
Now, we’re doing Gateway Routing, from IP to Hunt Group (which we created above).
And now a single IP to Hunt Group Routing rule: anything going to 911 go out FXO Hunt Group 1.
Now, let’s syslog and test this. This is a 911 call, so, have your, “This is not an emergency, I’m testing
911” script ready. This is a live 911 call. Be ready. Be careful. If you haven’t fully tested two-way audio
and they cannot hear you, they will roll emergency vehicles to your location!
25
www.mirazon.com

Notice that the call “seized” the FXO Port – it’s now Green.
And notice, that Syslog looks good. Since this went out FXO, the caller ID reflected the FXO line (the actual
phone company POTS line) not what the “from” was in the INVITE above (502-400-1975).
To clean this up, and make this a backup “outbound 911” config – I’m going to adjust the SBC route and
make 911 route “underneath” the default route.
26
www.mirazon.com

Finally with FXO, let’s play with Inbound. What if you wanted Incoming calls to an FXO port actually a
specific Lync/Skype number, like maybe a primary Auto Attendant or Response Group?
For our example, let’s say that if someone calls into our FXO (502-240-0409), we want that to ring
outbound to Lync/Skype and our Main auto-attendant (AA) (502-240-0404). It would build upon what
we’ve already done.
First of all, we build a Tel to IP Routing Rule – anything in from FXO 1 (Hunt Group 1) – and send that to
Destination IP Group 1 (Lync/Skype).
Then we have to build the “answer” rule.
27
www.mirazon.com

Now, any call into FXO 1 – 502-240-0409 – should automatically dial 502-240-0404 toward IP Group 1
(Lync/Skype).
Let’s syslog and test it.
It rings, then the AA picks up – and you can see FXO #1 seize as green.
28
www.mirazon.com

The Syslog looks good. But, oddly, the Caller ID doesn’t look right. Let’s see if we can correct that.
29
www.mirazon.com

There it is. Let’s Enable that and try again.
Much better!
We’ve added more detail to our architecture. Now it looks like this:
30
www.mirazon.com

To review what we have so far, we have active/working:
1) SIP Inbound from Intelepeer – default routing to Lync/Skype
2) SIP Outbound from Lync/Skype – default routing to Intelepeer
3) A route we can change order on to make 911 go out FXO if for some reason we need that and ...........
Intelepeer is down
4) FXO Inbound that is properly routing to Lync/Skype and our Main AA number – 502-240-0404
FXS Ports – Integrating with Lync/Skype and ITSP and E-SBC
We’re making great progress! We have fully working SIP and FXO. Time to add FXS to the mix.
Remember, in this Technical Guide, we’re adding features and building upon past successes.
I setup FXS Port #1 for 502-400-2349. This is a dumb little white Walmart phone.
31
www.mirazon.com

Make sure you set the Hunt Group Settings to “By Destination Phone Number” here.
Set a route entry. Anything from Hunt Group 2 (our FXS Port) – Route that out Destination IP Group 2
(Intelepeer). Notice that I left a lot of “empty rows” here. That’s on purpose. There is not an easy way to
reorder/renumber routing rules. I like to leave empty space for future additions/changes.
Let’s syslog and test.
32
www.mirazon.com

Looks good! You can see the “digits” of 502-751-2108 and the Invite going out to Intelepeer.
Note: I honestly don’t know why this shows up as X-Siemens-Call-Type: collect-call. If you know, please
let me know. I’ve seen that on an ISDN/PRI configuration, but not on an analog setup. As my friend
Yoav pointed out, this is typically something seen related to “facility” IE. Is this a “glitch” in this firmware
as related to analog deivces? Or is this something missed in configuration? Please dive in and point out
mistakes. We all like to learn!
Now, let’s expand this a bit. Now we want FXS to call certain numbers inbound (to Lync/Skype) and
other numbers outbound to Intelepeer.
33
www.mirazon.com

See that new Route #3? It’s above the FXS Call Out to PSTN. So, if you call 502-400-1965 (our dial-in
conferencing number) from the FXS Port, you go to Lync/Skype. Other numbers go out Intelepeer
(Route #5).
Let’s syslog and test.
34
www.mirazon.com

Looks good! You’re really putting it all together now.
Next up is inbound FXS – we want the Walmart phone to ring.
Let’s start by building the IP to Hunt Group Routing:
35
www.mirazon.com

Above you see the entry for 502-400-2349. No matter which IP Group (1 for Lync/Skype – 2 for
Intelepeer) – we go to Hunt Group 2. That’s what “-1” means on the far right.
Now, we need SBC routing so we can actually get this call to the Gateway side of the AudioCodes device.
This is the SBC Routing from 1 (Lync/Skype) to 502-400-2349 and it is “Above” the default route out to
Intelepeer.
And we need to address incoming calls from the ITSP as well.
This is the same as above except from 2 (Intelepeer) to 502-400-2349. Notice it also is above the
default route in to Lync/Skype.
Now, let’s syslog and test. We should now get the plastic Walmart phone to ring from both Lync/Skype
and also from the ISTP.
36
www.mirazon.com

Excellent – notice this is an inbound call from Intelepeer (502-751-2108) to 502-400-2349.
And now from Lync/Skype. Notice this is from the inside (502-400-1975) to 502-400-2349.
Once again, we’ve added more detail to our architecture. Now it looks like this:
37
www.mirazon.com

To review what we have so far, we have active/working:
1) SIP Inbound from Intelepeer – default routing to Lync/Skype
2) SIP Outbound from Lync/Skype – default routing to Intelepeer
3) A route we can change order on to make 911 go out FXO if for some reason we need that and
Intelepeer is down
4) FXO Inbound that is properly routing to Lync/Skype and our Main AA number – 502-240-0404
5) FXS Outbound that can properly route to Lync/Skype and our Public ITSP
6) FXS Inbound that can properly ring a device whether the call is originated internal (Lync/Skype) or
external (our Public ITSP)
MediaPack – Integrating with Lync/Skype and ITSP and E-SBC
Time to add an Analog Gateway into the mix. We want to be able to have a remote device – an
AudioCodes MediaPack 112 in our case – able to make and receive calls on Analog devices. Those
calls need to be both received from and destined for both Lync/Skype and the ITSP (via the E-SBC).
This is a slightly more complex discussion than we’ve had so far. The MP112 is IP 10.0.150.64.
38
www.mirazon.com

Let’s start with some of the choices we made on the E-SBC. Set the RFC 2833 (DTMF) TX and RX to 101
(default is 96):
Create Proxy Set 1 – pointing to Lync/Skype – srv-rtc04 in our case.
Create Proxy Set 2 – pointing directly to the Mediant E-SBC – srv-sbc02 in our case.
Create IP Group #1 for Lync/Skype.
39
www.mirazon.com

And Create IP Group #2 for the Mediant E-SBC.
40
www.mirazon.com

Like with the E-SBC, we have a few “general settings” we want to standardize on. Set default SIP
Transport Type to TCP.
Set Current Disconnect to ‘Enable’.
41
www.mirazon.com

Set Use Default Proxy – No. We’re going to set rules to route accordingly.
Choose both A-Law and U-law as coders. We typically will only be using G.711ulaw of course.
Let set FXS Port #1 for 502-400-2353
42
www.mirazon.com

And like we did on the E-SBC, set the Hunt Group Settings for FXS to be By Destination Number
For this example, I just created generic/default manipulation rules for both IP -> Tel and Tel -> IP – just
passing through digits.
I created four generic “from analog to IP” routing rules.
If you call 502-400-1965 or 502-400-1975 or 502-240-0404 – call Lync/Skype.
If you call anything else, it will call srv-sbc02 (so it will route out to Intelepeer ITSP from there).
Then, for IP -> Hunt Group routing there is just a single rule here: if you call 502-400-2353 and the call
makes it to the MP112 from anywhere (Source IP Group of -1), route that call to Hunt Group 1 (FXS #1).
To make sure nothing weird happens based on the number of digits dialed, let’s make the maximum
number of digits something large – larger than you would normally dial.
43
www.mirazon.com

Great. The MP112 looks reasonably complete. Let’s briefly discuss Lync/Skype.
Previously, we’ve already added the MP112 as a TCP/5060 gateway via the topology and properly set
up Gateway, Policy, PSTN Usages, Routes, etc. This guide is focused on AudioCodes. Use your existing
Lync/Skype knowledge accordingly.
Short version: we have a “csanalogdevice” with LineURI of +15024002353. We have routing rules setup
pointing anything that resolves to +15024002353 to the MP112. Then, at the Trunk Level – based on
the above config (expecting 10 digits) – I have a rule that strips off the +1.
At the incoming level, there is no “Pool Dial Plan” for the MP112, so, all number normalization rules
happen at the next level, the SITE in our case.
Let’s test by turning on syslog on the MP112 and capturing info.
44
www.mirazon.com

That looks good! Looks like a good call from the FXS MP112 to 502-400-1975 – my Lync/Skype
endpoint.
And the other way?
45
www.mirazon.com

This is Lync/Skype to MP112 FXS call… yay! Works great!
Notice the CallerID shows +15022400404 because, in the Lync/Skype Route, I’m not suppressing Caller
ID from me. It’s coming from my full LineURI +15022400404;ext=566
What’s left? Oh yeah – let’s get the Mediant E-SBC set up properly and test public calls too.
Head to the E-SBC and start by creating a new Proxy Set for the MP112 @ 10.0.150.64 with TCP/5060
And then we’ll need a new IP Group for proper routing of the call at the E-SBC level.
46
www.mirazon.com

www.mirazon.com
47

Okay, I set up the IP Group for the MP112. I’m using SRD 1 and Realm1 – this is all “inbound / LAN” to
the SBC.
Notice that I set IP Profile 3 though, so we have to configure that.
48
www.mirazon.com

Note: Media Security Disable
49
www.mirazon.com

Okay. That’s the IP Profile 3, so that should be good to go.
Time to do routing.
50
www.mirazon.com

Okay, Route 4 – this is “above” the default route of 2-1 (Intelepeer/ITSP to Lync/Skype) – so – anything
from 2 (Intelepeer) that’s destined for 502-400-2353 – route that to IP Group 3 – MP112.
That’s good. Now the other way.
51
www.mirazon.com

Okay, Route #7: Anything from MP112 (IP Group 3), send that to IP Group 2 (Intelepeer).
Now, let’s test.
52
www.mirazon.com

Okay, here’s the trace from the Analog FXS port to the MP112 that then sends it to the Mediant SBC
(10.0.99.240). So far so good.
53
www.mirazon.com

And there is the full call from the SBC perspective. The call comes from MP112 (10.0.150.64) and then
routes and works appropriately via Intelepeer. This is a very good test. Yay! Now inbound.
54
www.mirazon.com

Okay, that’s nice. Inbound to 502-400-2353 gets to the E-SBC then routes properly to the MP112.
55
www.mirazon.com

Great! And the call continues to the MP112 and rings properly.
Also… what about a full “triangle” of calls? That is… what if I want to call from the MP112 to the SBC and
then back to Lync? And vice versa?
That’s easy. It’s all about how you setup your routing tables in each device. Let’s modify our MP112
routing table and remove the route for 502-400-1975. If you recall, we had that route set to go to Lync
directly. By removing that specific route (red highlight below), the call will be forced to head to the
E-SBC instead (IP Group 2).
56
www.mirazon.com

Then on the SBC – notice that I have Route 7 (a new Route 7) above Route 8. This means if anything
comes from IP Group 3 (MP112) destined for 502-400-1975 – send it out IP Group 1 (Lync).
Let’s test that again with syslog.
57
www.mirazon.com

MP112 to SBC at 10.0.99.240 looks good. Let’s keep going.
58
www.mirazon.com

And the whole route from MP112 (10.0.150.64) to the E-SBC (Device) to Lync/Skype (10.0.99.178) looks
good. That’s great.
One more test case to complete our triangle. We should test an inbound call from the ITSP to the
E-SBC to Lync/Skype to the MP112.
We’ll start by creating another FXS port on the MP112 for 502-400-2355.
59
www.mirazon.com

Next we’ll create an analog device on Lync/Skype – something that will be available via Reverse
Number Lookup (RNL) and properly route to the MP112.
And we’ll assume that Lync/Skype is set up properly to handle the E.164 form of that number and
manipulate it before it heads off the MP112, which it does J
So, putting that together… if we make an inbound call to 502-400-2355, the route should be ITSP ->
SBC -> Lync/Skype (RNL) -> MP112 -> Phone 2355 (FXS Port #2).
Let’s syslog and test that.
60
www.mirazon.com

So far so good. The call from 502-751-2108 to 502-400-2355 comes from the ITSP to the E-SBC
(device) and ships off to Lync/Skype (10.0.99.178) just fine.
61
www.mirazon.com

And, from Lync/Skype (10.0.99.178) to the MP112 (Device) to FXS Port #2 (Ch:1). This call is complete.
Once again, we’ve added more detail to our architecture. Now it looks like this:
62
www.mirazon.com

To review what we have so far, we have active/working:
1) SIP Inbound from Intelepeer – default routing to Lync/Skype
2) SIP Outbound from Lync/Skype – default routing to Intelepeer
3) A route we can change order on to make 911 go out FXO if for some reason we need that and
Intelepeer is down
4) FXO Inbound that is properly routing to Lync/Skype and our Main AA number – 502-240-0404
5) FXS Outbound that can properly route to Lync/Skype and our Public ITSP
6) FXS Inbound that can properly ring a device whether the call is originated internal (Lync/Skype) or
external (our Public ITSP)
7) Full MediaPack MP112 Integration with both Lync/Skype and E-SBC and ITSP
a. SIP inbound to E-SBC to MP112
b. SIP inbound to E-SBC to Lync/Skype to MP112
c. MP112 to Lync/Skype
d. MP112 to E-SBC to Lync/Skype
e. MP112 to E-SBC to ITSP
f. Lync/Skype to MP112
g. Lync/Skype to E-SBC to MP112
Intra-E-SBC Routing – FXS FXO & FXO FXS
Let’s add another scenario to the mix. What if we wanted to route internally between FXS and FXO?
There’s no easy way to do this from hunt group to hunt group, so we have to mix both SBC and
Gateway routing methodologies within the E-SBC itself.
63
www.mirazon.com

Let’s discuss the following use cases
1) FXS outbound to FXO – maybe an analog extension like a lobby phone, or maybe an elevator that
wants a failover route to go out FXO if the primary IP / SIP Route is down.
2) FXO inbound to FXS – maybe like a fax machine pass-through
Let’s review our FXS and FXO Port Hunt Group settings.
We have FXO #1 set up and attached to the fax line we got from the telco.
We have FXS #1 set up for a Walmart phone: 502-400-2349
We have FXS #4 set up for our own fax machine: 502-240-0409
And, our Hunt Group Settings are what they were before in previous examples: Cyclic Ascending for
FXO and By Dest Phone Number for FXS.
Great. Now what? Well, we want to do some routing. But before we can route, we have to set up more
information, of course. We know that routing has to have a destination. We need to start by creating a
Proxy Set for our own “internal” destination.
64
www.mirazon.com

I created Proxy set #10 (because it’s a good round number) – pointing to our internal LAN IP of
10.0.99.240 / TCP / 5060.
Now we need an IP Group for routing.
65
www.mirazon.com

www.mirazon.com
66

Notice that I made this reference Proxy Set ID #10 (the one I created above). I also chose SRD 1
and Realm1 – this is an “internal / LAN” thing. This is similar to why I chose those options in previous
documentation related to the MP112. Some people don’t like using terms “SRD” or “Realm” and prefer
more friendly names to explain what they are. At the basic (high level), realms are a collection of ports
for your RTP traffic, and SRD is a collection/definition of IP interfaces, and usability stuff from the user
perspective. Yes, that’s vague. Both are important to understand – so – consult your user and admin
manuals here.
Likewise I chose IP Profile ID 3. That’s the IP Profile I chose for the MP112. Why? Because I specifically
wanted this profile to NOT use media security. Making another IP Profile isn’t a bad idea, but for this
example, I chose to use shared IP Profiles between the MP112 and internal device.
Okay, we have a Proxy Set. We have an IP Group. Now, let’s route.
The route to pay attention to here is #4. From Source Hunt Group 2 (the FXS Ports), if you dial seven
digits 7512108 (local calls are seven digits in our location) – we want this to route to IP Group 10 (the
one we just created for “internal routing”). But, remember, we’re an SBC so we need SBC routing too.
67
www.mirazon.com

www.mirazon.com
68

See that route #1? That’s Internal SBC Routing. The Source IP Group is 10. The destination is the
Gateway itself. This should be familiar based on the other testing/documentation we discussed up to
this point.
Okay, so, we routed from Tel to IP using SBC Routing to get to the Gateway and now we need IP to Tel
routing. I know, it’s kind of circular.
Okay, so if anything comes to the Gateway and is destined for 7512108, send it out hunt group #1 –
the FXO. This looks complete. Let’s test with syslog.
69
www.mirazon.com

That looks good. The phone went off hook, dialed 7512108, and the route went to itself at 10.0.99.240.
70
www.mirazon.com

Then, the route happened internally, and the route came from itself 10.0.99.240 and out the FXO Port.
Now, what about inbound? What if we wanted to an incoming FXO port to ring an FXS port on the
device itself. This use case may be an analog extension passthrough or fax passthrough.
Consider the configs to be similar: hunt groups, hunt group settings, IP groups, profiles, etc.
The Tel to IP Routing is a good place to start this time.
71
www.mirazon.com

Notice line #1 – I have this set up already for FXO/FXS FAX Passthrough. Let’s adjust that because we
want to test this with a white Walmart phone to more easily capture syslog.
Okay, the route now goes to 502-400-2349 like we want, but I need to tell the FXO to dial 502-400-
2349 now instead of the fax number we had.
Now, let’s test with syslog and see what happens. We are going to call 502-240-0409 (the PSTN line
plugged into FXO #1). Notice it turns green when dialed.
72
www.mirazon.com

Also notice that FXS #1 is up (the 502-400-2349 entry we auto-dialed).
73
www.mirazon.com

That’s good. My cell 502-751-2108 called 502-240-0409 (the FXO Port) which immediately was set to
call 502-400-2349 (based on the screen shots above).
This call went straight to 10.0.99.240 (the gateway itself).
74
www.mirazon.com

Then the gateway 10.0.99.240 routed back to the device and out Ch:4 which is FXS Port #1.
We now have FXS to FXO (outbound) and FXO to FXS (inbound) working alongside our other routes
we’ve built on with SIP Trunks and MP112 devices, etc. For completion, in our specific case, we set
things back to inbound calls to FXO going to 502-240-0409 which is FXS #4 – our fax machine.
And again, we’ve added more detail to our architecture. Now it looks like this.
75
www.mirazon.com

To review what we have so far, we have active/working:
1) SIP Inbound from Intelepeer – default routing to Lync/Skype
2) SIP Outbound from Lync/Skype – default routing to Intelepeer
3) A route we can change order on to make 911 go out FXO if for some reason we need that and
Intelepeer is down
4) FXO Inbound that is properly routing to Lync/Skype and our Main AA number – 502-240-0404
5) FXS Outbound that can properly route to Lync/Skype and our Public ITSP
6) FXS Inbound that can properly ring a device whether the call is originated internal (Lync/Skype) or
external (our Public ITSP)
7) Full MediaPack MP112 Integration with both Lync/Skype and E-SBC and ITSP
a. SIP inbound to E-SBC to MP112
b. SIP inbound to E-SBC to Lync/Skype to MP112
c. MP112 to Lync/Skype
d. MP112 to E-SBC to Lync/Skype
e. MP112 to E-SBC to ITSP
f. Lync/Skype to MP112
g. Lync/Skype to E-SBC to MP112
8) Intra-E-SBC FXS Routing out to FXO
9) Intra-E-SBC FXO Routing in to FXS
Failover (Alternate) Routing on E-SBC with Manipulation
Okay, we’ve made a ton of progress. Here’s one more topic to discuss in the scope of this technical
guide. There are no architecture changes at this time. We need to address failover (or alternate)
routing. Up until this point, I’ve referenced voice routing tables as “routing table order” and that is
mostly true,
76
www.mirazon.com

ut AudioCodes does not do failover routing in the way you’d think. It’s not ONLY “routing table order”
based. I admit, I set you up a little bit here in the examples in the document so far. Sorry, not sorry.
You would think if you have two identical routing table/statements, it would try the first, and if it failed,
it would go down the list to the next. That’s fairly accurate in many E-SBC solutions, but that is not the
case with these specific scenarios with SBC routing in this technical guide.
In general, for something to fail and need an alternate route, you probably get one of three SIP
responses back – 500, 503 or 487. There are more options, but, those are typically the ones you get.
Let’s build some rules to capture these reasons.
Okay, if we get a SIP Response as 487, 500, or 503 then that’s a legitimate reason to use Alternative
Routing. Again, your mileage may vary here.
Now, let’s build/adjust the routes we’ve discussed up to this point and actually give them useful names
based on routing scenarios discussed.
Notice Index #2 – that’s Skype to ITSP (Intelepeer) for 502-751-2108.
Let’s build an identical route with alternative routing options pointing to the Gateway so it can route
out FXO. We want to make sure the call works if the ITSP goes down.
77
www.mirazon.com

See that? The routing order is correct – ITSP ahead of FXO. So, routing table order matters.
But notice I changed the Alternate Route Options to “Alt Route Consider Inputs”. That means that if the
SIP RESPONSE (input) matches 487, 500, 503 then use this route. Got it?
So, we have a route that should call 502-751-2108 via ITSP, but if ITSP isn’t available, my then 502-751-
2108 should be called out FXO. But in our case, specifically, we can’t dial 10 digits out FXO for a local
call. You should remember that from the previous section. So we have to manipulate that for an IP ->
Tel call.
This rule is so if a call is routed IP -> Tel destined for 502-751-2108, strip three digits from left and
make it 751-2108.
And the routing table should then send 751-2108 out Hunt Group 1 – the FXO Port – based on
previous tests.
78
www.mirazon.com

But notice the IP-to-Tel Routing Mode is “Route calls before manipulation”, so we need to have
a 10 digit route for 502-751-2108 so there is a routing destination before our three-digit strip/
manipulation.
Make sense? We’re adding more and more complexity and options and rules to our architecture to fit
with various use cases.
Let’s test to make sure our ITSP call works properly.
Looks good. Lync/Skype to 502-751-2108 via ITSP (68.68.117.67).
79
www.mirazon.com

Now, let’s make sure the ITSP fails. Unplug the WAN cable. We can see below the before state – FXO
#1 is connected. And LAN #3 is connected for WAN.
After: LAN #3 is dead. Any calls out should now fail; however, any calls to 502-751-2108 should reroute
out FXO after being properly manipulated to 751-2108.
80
www.mirazon.com

Let’s test that…
Well, FXO #1 picks up. That’s good!
81
www.mirazon.com

Weird, why don’t we see the failover happening here? We know the failover happens. We see it visually
because the FXO port goes active. The call happens.
Let’s go back to the syslog/traces in a little more detail.
82
www.mirazon.com

Okay, the call happens (obviously) but when we scroll down a little more in the traces we see more.
Ah, okay. Alternative Routing happens. This is good. And then we see more...
There it is: Routing Rule #3 (the alternative route to the gateway). And the call goes forward.
83
www.mirazon.com

Let’s zoom in to see that in a little more detail
Notice the routing takes place – 502-751-2108 is the destination. Then Manipulation happens
removing three digits from the prefix turning it into 751-2108. This is exactly as we expected. Then
back to normal / typical routing:
So, the Syslog/SIP Traces saw all the logic and what happened, but the SIP Flow Diagram doesn’t,
because the only SIP Flow that actually stood up and tore down was the SIP Flow out FXO. The rest of
all of this was internal E-SBC logic. It’s been pointed out that some SBCs have built-in-logic to do FXO
FXS failover. I did not touch on that in this guide. If you have specific examples of how this may
work, I’d love to know that so I can make this document more accurate.
Even though this example was specific to handling 10 digits 502-751-2108, this would more likely be
used for useful things like 911, or whatever else you deem critical.
In this section we specifically called out ITSP failover to FXO; however, that is not the only use case
here. You can extrapolate alternate routing from ITSP to ITSP or inbound calls as well that primarily are
answered by Lync/Skype but failover to an FXS line. Be creative.
To review what we have done in this technical guide, we have active/working:
1) SIP Inbound from Intelepeer – default routing to Lync/Skype
2) SIP Outbound from Lync/Skype – default routing to Intelepeer
3) A route we can change order on to make 911 go out FXO if for some reason we need that and
Intelepeer is down
4) FXO Inbound that is properly routing to Lync/Skype and our Main AA number – 502-240-0404
5) FXS Outbound that can properly route to Lync/Skype and our Public ITSP
6) FXS Inbound that can properly ring a device whether the call is originated internal (Lync/Skype) or
external (our Public ITSP)
84
www.mirazon.com

7) Full MediaPack MP112 Integration with both Lync/Skype and E-SBC and ITSP
a. SIP inbound to E-SBC to MP112
b. SIP inbound to E-SBC to Lync/Skype to MP112
c. MP112 to Lync/Skype
d. MP112 to E-SBC to Lync/Skype
e. MP112 to E-SBC to ITSP
f. Lync/Skype to MP112
g. Lync/Skype to E-SBC to MP112
8) Intra-E-SBC FXS Routing out to FXO
9) Intra-E-SBC FXO Routing in to FXS
10) Failover / Alternate Routing to ensure critical dialing outbound or inbound is addressed
85
www.mirazon.com

Technical Guide – Usage and Licensing Terms
The following contains detail the actual licensing / usages of this document.
• This document is a freely licensed technical work. It was written and distributed by Mirazon –
Mirazon.com – Louisville, Kentucky, USA.
• As the licensee of this technical guide, you received this document under a license agreement
which includes both copyright as well as authorized, enforceable usage restrictions.
• If you received this document from any other source than Mirazon.com, please contact us – info@
mirazon.com - to ensure you have received a complete and unedited copy of your own.
• You are permitted to use the document provided exclusively for the purpose of performing work
related to what it describes, or preparing yourself in a matter of training or education on that
purpose.
• We consider it fair that someone you know personally might be given the opportunity to casually
review your materials or tools in the context of deciding if they would value having a copy of this
technical guide of their own. We also consider it fair to present this appropriate portion of your
documentation to a customer or prospect for whom related work is involved, where adequate
disclosure of the method involved is requested. However, please treat the shared access to our
documentation and tools as training material for which the right to use it in that manner is
yours, and yours alone.
• You may not place any hard copy, or electronic copy, of any portion of this technical
documentation in a location that provides anonymous access.
• You may not store or locate this document in any manner which encourages, or permits violation
of the license agreement or copyright such as with file swapping / sharing technologies.
• Under no circumstances are you allowed to take portions of this document and share them
with anyone else, without obtaining specific and written authorization from Mirazon.com for that
purpose. For example, posting sections of this documentation to the Internet or public network,
or private network are all examples in violation of our license and copyrights. As the document is
freely licensed and distributed, kindly direct others to Mirazon.com for their own copy.
86
www.mirazon.com