Cisco Unified Communications Manager Express Call Flow
Now let's look at the Communications Manager Express call flows and call legs. Here, we use dial-peers to establish the connections. What I want you to think of right off the bat is that to make an end-to-end call we would have to configure 4 dial-peers and dial-peers associate with call legs. So, for every call leg there's a dial-peer. So if you were to be asked for an end-to-end call how many call legs or dial-peers do you have, the answer's 4, doesn't matter just kind of think of them as one in the same. With our addressable end points we could have POTS dial-peers. This is a traditional telecommunications device such as a single line phone, a fax machine, that could all be a POTS dial-peer. A VOIP dial-peer connects across our packet network, so we're going to be using IP addresses. We're going to be saying "oh to reach this particular number go to this gateway" and you'll put the IP address in or "go to this Communications Manager solution", and we'll be putting in the IP address. IP phones are POTS dial-peers from the Communications Manager expresses perspective. Dial-peers are defined for outgoing destinations and we also have a dial-peers for incoming calls. There's something called a default dial-peer that could kick in on an incoming call situation. Here's why - so default dial-peer think about this is something you didn't configure. If I know where something came from I can send it back in that same direction. So if something comes into me and I don't have a dial-peer configured for example the router can say "oh well I know where that came from I'm just going to send these packets back that same path". But for outgoing if I don't have a dial-peer configured how do I know where to send it. So that's how that default dial-peer will work for incoming calls. I don't recommend that you rely on this because it's non-configurable. You get what you get and we'll see some information about that too coming up.
Cisco Unified Communications Manager Express Call Legs
We have different dial-peers and of course a dial-peer equates to a call leg. We have POTS and we have VOIP. In order to make an end-to-end call we need 4 call legs. We'd have two inbound and two outbound.
The inbound call leg you can see on the picture above has a POTS call leg in this example and the outbound call leg is a VOIP call leg. It's probably pointing out to another router or a Communications Manager Express that might be sitting out there and then from the opposite side we would have an inbound VOIP call leg and then another outbound call leg to whatever phone destination we are attempting to reach.
POTS Dial Peers
First let's create our POTS inbound dial-peer. The basic configuration is given below the following example:
Branch1(config)#dial-peer voice 1 pots
Let's say that it was a PBX we have plugged in and we probably would have a variety of extension numbers but for the example they were in the 7000 range. I don't have to create 7999 dial-peers I can use a wild card. I could've said 7... and so now everything in that 7000 though 7999 range would be associated with this dial-peer. Now finally, to make the final association we have to specify the port that this is located on so we then use our port command, specify the port number and now we're done creating this inbound POTS dial-peer.
VoIP Dial Peers
Now let's look at configuring a VOIP dial-peer. But first, let's go ahead and create another POTS dial-peer, because we're going to need to specify all of the extensions that live at that Branch 2 location which are in the 8000 range.
Branch2(config)#dial-peer voice 3 pots
Now, something that's unique about a POTS dial-peer - it will only forward wild card digits not explicitly matched digits. What do I mean by this? If I dialed 8888 the only digits forwarded off to the PBX would be 888 that might not be enough, so what can I do to make sure that all the digits are forwarded. One command I can use is forward-digits all. Now, it looks at that incoming number and it forwards all 4 digits.
Let's look at our VOIP dial-peer. It's dial-peer voice again a locally significant digit and now the key word is voip instead of pots. We still use our destination-pattern command and we can specify the digits 8... In this VOIP dial-peer it differs from a POTS dial-peer all digits are forwarded it's just the way that it is. And very important, people forget this a lot, we have to specify that it is an IPV4 address.
Branch2(config)#dial-peer voice 2 voip
Branch2(config-dialpeer)#session target ipv4: 10.18.0.1
Matching Inbound Dial Peers
There are several ways that we can match an inbound dial-peer. We can use several different commands within the dial-peers as those numbers come in, it will look to match these. Now there's a certain order too that it looks at these numbers. First of all, for matching an inbound dial-peer we have the incoming called-number command. This defines the dialed number information service string. So, what number was dialed? If that number matches that dial-peer, boom we are coming in. We could also look for the answer-address command. This is looking at the ANI - the caller ID in other words – and this applies to your VOIP, your POTS, your T1, E1 CAS connections and your ISDN dial-peers. We also have seen the destination-pattern command. We can use this for the ANI string to match and it'll match an incoming call leg on an inbound dial-peer. Finally, we have the port command. So the port attempts to match the configured dial-peer port to that voice port that it's associated that incoming call with. This is only on a POTS dial-peer, because we don't use the port command in a voice over IP dial-peer.
If no match is found, if we don't have an incoming called number match and answer-address or a destination pattern, or port the final inbound-only solution is that default dial-peer. This default dial-peer basically exists, it's non configurable and it's only inbound because again if I've got something coming into me I know where it came from so I can send traffic back that direction. So on an inbound dial-peer if none of these four match the final attempt is to use the default dial-peer, dial-peer 0 they call it. And if you did show commands you won't even see it. So it's not like if you looked at your dial-peers you'd see this default dial-peer out there you can't even see it you can't modify it. So, it's not good to rely on that but it is there as a catch-all in case for some reason we didn't match any of these other configured parameters.
With that default dial-peer we want you to see what the parameters are, because again these are non-configurable, again it's only inbound dial-peers and basically it'll take any codec that comes in its way. Voice activity detection is enabled, any DTMF relay is completely disabled. So if we had SIP going on here we might have an issue. We have certain markings for quality of service that are applied, DSCP markings for the signalling or AF31 and EF for the RTP and there's no RSVP support. Really, it's very very limited and that's why I always suggest you don't leave no incoming dial-peer match. In other words you don't want the default dial-peer to kick in. You want to have a match based on your other parameters.
Matching Outbound Dial Peers
Let's look at outbound matching of our dial-peers. This is kind of interesting because basically the rule of thumb, is the shortest solution is the one that we're going to choose or the most specific.
!dial-peer voice 911 potsdestination-pattern 911forward-digits allport 0/0/0:23!dial-peer voice 9911 potsdestination-pattern 9911forward-digits 3port 0/0/0:23!dial-peer voice 97 potsdestination-pattern 9[2-9]......port 0/0/0:23!dial-peer voice 98 potsdestination-pattern 91[2-9]..[2-9]......port 0/0/0:23!dial-peer voice 91800 potsdestination-pattern 91800.......port 0/0/0:23forward-digits 11!dial-peer voice 9011 potsdestination-pattern 9011Tprefix 011port 0/0/0:23!
So if we had a dial-peer for example that explicitly had a destination pattern of like 911 and that's what we dialed. We might match other dial-peers but because 911 was typed out explicitly and that's what we dialed that is the dial-peer we would match. So, you can see some great examples of various dial-peers created here. We've got a 911 POTS. It's always a good idea to make sure that we have a 9911 as well because sometimes you know people know I got to dial 9 to get an outside line, so they're going to dial 9911 or in a panic they don't think of that and they just dial 911. These are POTS dial-peers. So, you have to say forward-digits all, especially with 911 we want all three of those digits to go, if we did not specify forward-digits all nothing would happen, that's not good.
Now, in the 9911 option we know that the PSTN is not looking for that extra 9 access code, so instead of saying forward-digits all we could say forward-digits 3. The last three digits the way it works it's not like we read it's from right to left. So we look at the 1 the 1 and the 9 those are the three digits that's what we would forward. We also have some additional POTS dial-peers that explicitly matched destination patterns for local and long distance and even 800 numbers. You can see the destination pattern examples they gave you. I highly recommend that you try to be very specific with your destination patterns, because you could just go in and put in 7 dots, that would match a local number, but something that we know, we know that an area code or an exchange does not start with a zero or a 1. So we use the brackets and we say okay any number 2 through 9 is an acceptable number. So now for example dial-peer 97 has a destination pattern of 9 and then it has a 2 through 9 so that means that number could be a 2 or a 3 or a 4 – it can't be more than one digit, it's got to be one digit that matches the range that we see in brackets and then the dots each represent one digit. So, in this instance we would have I'm thinking it's looks like a 7 digit number that we could match for this particular dial-peer and then they do the same thing with long distance and then even an 800 number. Now something that they neglected to do on dial-peer 97 and 98 is put in any type of forwarding command. Now is this a good thing or did they make a mistake? We'll think about it. [2-9] that's a wild card. The 9 is our internal access code. We don't want the 9 to go. So they didn't need to use a forwarding command for these digits because the 9 gets dropped because we don't send that – it's an explicit match. Everything else is a wild card so everything else would be forwarded out the PSTN. We also see that with the 800 number but they've used the forwarded-digits command and they've said okay we want to make sure that that 800, 1 800 goes out to the PSTN so they've now said forward-digits 11 so that number would appropriately be sent out to the public switch telephone network. And then finally they have a dial-peer 9011, it's international, and 9011 is our internal access code is the 9 and 011 is the country code. The T represents any number of digits. One of the things that happens with international numbers is they aren't always the same length – isn't like with us where it 7 digits local or 10 digits local and 11 digits long distance. In Germany and some of the other places the numbers vary in length so the T says okay whatever numbers you've got after dialing 9011 this is the dial-peer you're going to match.
Now, to send a call out to the PSTN we need to make sure we include the country code. So what we've done the T is the wild card so those digits would be sent but we've prefixed 011 to the front of that number, because again if we try to use that forward-digits command we may not know what digits are going to be needed for that number to be formed and we don't want the 9 to go out. So this is the best solution I think for an international dial-peer that we might want to have set up. So, great, great look at all of the different types of configuration we could possibly do with our POTS dial-peers. Of course you know there is a lot more that we can do out there but this gives us a nice starting point so that we can make calls out to the public switch telephone network and make sure that all of the appropriate digits have been sent.
Influencing Outgoing Call Behavior
Because we could have a number of dial-peers possibly matching an outbound call we can actually influence the dial-peer that's chosen. First of all we could use the longest match if there's multiple matches or we could use a preference command. The preference command is a number that ranges from 0 through 7 and lower score wins. By default if you create a dial-peer and you don't specify a preference its preference is 0. Now let's say we had two dial-peers maybe going down different paths. We could set the primary as preference 0 and then maybe an alternate as preference 1 so if 0 wasn't available or we couldn't make the call through that dial-peer we could then go to a secondary dial-peer and so on. You know we could have several different dial-peers here. If we don't specify any preference it's not really load balancing it's just kind of a random selection that goes on behind the scenes. Now we can modify that hunt behavior using the dial-peer hunt command and there's eight variants and different combinations that could be selected. We could say longest match, explicit preference, let it be random, least recent used. We could also have least recent used with an explicit preference and a longest match in the phone number. We could have least recent used with longest match in the phone number and explicit preference, and with the explicit preference we could also go down a path where it's the longest match in the number or the least recent used so you can see how there is multiple patterns that we can use to manage that hunting behavior through the various dial-peers.