Noob Call Routing question...

chmorin

I am learning enterprise voice at the moment but had some fun with dial peers and CME configs between different CME routers. In a CCUM environment, how is call handling managed? I have glanced through the chapter, don't have time to read right now, and from what I can tell there are Route Groups and Route Lists to configure digit manipulation and some other stuff.

Say I have a cluster and a bunch of other routers connecting to it from a WAN. How do the sites connect to the cluster, and how does call routing occur?

Maybe that didn't make any sense... I'm a pretty noob at large scale voice implementations but I'm working in one so I gotta charge into it. Let me make a small diagram:

CUCM Cluster -> SW 1 -> R1 <---> R2 -> [Cisco IP PHONE]
________________________\PSTN/

If I had voice gateway capable routers inbetween, how can I get the IP phone to register with the cluster, and how does it get its call routing commands? From the voice gateway, or from the CUCM cluster?

I hope these aren't to stupid questions, but the texts and white pages I have read have not gone into details as to how to configure and how the process is carried out. Only more of what is happening, which is useless to me in this case.

GT-Rob

When you say the PSTN is between R1 and R2, is that for IP traffic, or just calls?


If its the 2nd, then the phones are not going to register with the CUCM cluster as they have no way to reach it via IP, unless there is some WAN connectivity elsewhere. For example, how does anyone at that site reach the site at R1? A tunnel over the internet? MPLS?

If not, then they will need to register with the router itself, like if it was running CME. In reality though, you would probably have some kind of IP connectivity to that site.



We have a similar setup here, however there is an additional connection (MPLS) that allows the phones to register with the CUCM cluster, and then use its gateway (R2) for PSTN calls. The router then has something called fallback-mode (SRST) in case the WAN goes down, in which case the phones register to the router until it comes back up. They lose things like voice mail though during this.



As for call routing.....again in the case you have connectivity to the CUCM from all phones, then the CUCM Cluster is going to handle it (route partitions, etc). If the sites are truly standalone, then you likely just have the PSTN handling it all, and the VoIP is just for internal use (so you don't need a stupid PBX there). If you have multiple paths on the router (say a link to a PBX, a link to the PSTN, a link to the CUCM, a link to some FXS ports, etc), then dial-peers on the router can match the numbers to an outgoing interface just like a static route would in the routing world.

chmorin

GT-Rob wrote: »

When you say the PSTN is between R1 and R2, is that for IP traffic, or just calls?


If its the 2nd, then the phones are not going to register with the CUCM cluster as they have no way to reach it via IP, unless there is some WAN connectivity elsewhere. For example, how does anyone at that site reach the site at R1? A tunnel over the internet? MPLS?

If not, then they will need to register with the router itself, like if it was running CME. In reality though, you would probably have some kind of IP connectivity to that site.



We have a similar setup here, however there is an additional connection (MPLS) that allows the phones to register with the CUCM cluster, and then use its gateway (R2) for PSTN calls. The router then has something called fallback-mode (SRST) in case the WAN goes down, in which case the phones register to the router until it comes back up. They lose things like voice mail though during this.



As for call routing.....again in the case you have connectivity to the CUCM from all phones, then the CUCM Cluster is going to handle it (route partitions, etc). If the sites are truly standalone, then you likely just have the PSTN handling it all, and the VoIP is just for internal use (so you don't need a stupid PBX there). If you have multiple paths on the router (say a link to a PBX, a link to the PSTN, a link to the CUCM, a link to some FXS ports, etc), then dial-peers on the router can match the numbers to an outgoing interface just like a static route would in the routing world.

This pretty much answered my question, thank you so much!

Essentially we have a T1 I believe connecting their gateways with our CUCM cluster. It sounds to me from what you said that the individual gateways could control call routing, as can the CUCM. So if I have a problem with a particular number not getting processed by a particular partition those are the two things that I should check: The configuration on the gateway, and the configuration on the partition.

Thank you for your help and explanation!

GT-Rob

yeah a pretty common setup is to have your gateways act as just an outside link to the PSTN, and internally everything is handled by the CUCM. You still need dial-peers on the gateways so it knows how to route the traffic, but they are usually pretty simple until you get overlapping technologies (like half your users on a pbx, a few FXS ports, etc). Then the gateway is configured for SRST in the case it can't reach the CUCM, the phones fall back and register with the router (so internal to that site still works).

chmorin

GT-Rob wrote: »

yeah a pretty common setup is to have your gateways act as just an outside link to the PSTN, and internally everything is handled by the CUCM. You still need dial-peers on the gateways so it knows how to route the traffic, but they are usually pretty simple until you get overlapping technologies (like half your users on a pbx, a few FXS ports, etc). Then the gateway is configured for SRST in the case it can't reach the CUCM, the phones fall back and register with the router (so internal to that site still works).

That is essentially but I am reviewing the gateways (contractors did it before I arived) and the dial peer's don't make any sense. We have one pots dial peer with 9T and no session target... and another voip dial peer with "32.." with the target as the cluster. (32 is not really the first two digits, btw.)

The gateway for our other site, which can properly route the call, has no dial-peer's at all. It isn't even configured for SRST, which the other one is.

At this point all I know for sure is if I point their CSS to the other gateway, it can route the call.

pitviper

Are they H.323 gateways, or MGCP? If MGCP, the dial plan configuration is within CUCM - the local dial-peers might just be left over from something else.

chmorin

pitviper wrote: »

Are they H.323 gateways, or MGCP? If MGCP, the dial plan configuration is within CUCM - the local dial-peers might just be left over from something else.

Roger that, it is MGCP. WTF... they both have different call agents. The one that is not routing the call is point to the call manager cluster... the other is pointing elsewhere. Time to figure out what that is about...

also I used that tool you showed me to test how CUCM would handle the call, and it forwards it. Not sure still... not sure...

EDIT:

Oh holy crap on is pointing to the publisher and the other the subscriber... how should this work? Shouldn't they both point to the SUB? Might be worth noteing that the one that is not working is pointing to the PUB.

pitviper

Under "Gateways" in Call Manager are they all listed as "registered"?

chmorin

pitviper wrote: »

Under "Gateways" in Call Manager are they all listed as "registered"?

None of them actually say "Registered" but they both show up. (All of our gateways show up.)

EDIT: I'm starting to think that isn't the problem... Hmm...

pitviper

chmorin wrote: »

Oh holy crap on is pointing to the publisher and the other the subscriber... how should this work? Shouldn't they both point to the SUB? Might be worth noteing that the one that is not working is pointing to the PUB.

Not necessarily - the duties are often split amongst the servers for load balancing. The CM groups might look something like this

PHONE GROUP_A - Primary CM: PUB Secondary CM: SUB
PHONE GROUP_B - Primary CM: SUB Secondary CM: PUB

Of course if there is a replication issue....

chmorin

pitviper wrote: »

Of course if there is a replication issue....

With the first bit I think I just came to that being the way it is set up after digging a little deeper. I am brand new to this setup but I am loving it.

Anyway, can I force a replication?

PS: I was going to add REP to you but apparently I have to recently, but I just wanted to tell yah you are my new god of VOIP!

pitviper

chmorin wrote: »

Anyway, can I force a replication?

Do you have a CBT Nuggets streaming account, or access to the TUC series? Jeremy does a nice job of explaining replication issues - From there you'll see why you'll probably not want to be the one to mess with it in a CM 4.x environment

Hopefully that's not the issue.

chmorin

pitviper wrote: »

Do you have a CBT Nuggets streaming account, or access to the TUC series? Jeremy does a nice job of explaining replication issues - From there you'll see why you'll probably not want to be the one to mess with it in a CM 4.x environment

Hopefully that's not the issue.

No I don't but I was going to soon for my CIPT1 track. I'll start researching it then and let you guys know what I come up with.

Thank you for your help. We will be updating eventually... hopefully sooner than later.

EDIT:

Well, the site with the problem is pointing at the PUB... so could a replication issue really even cause this?

pitviper

chmorin wrote: »

Well, the site with the problem is pointing at the PUB... so could a replication issue really even cause this?

Ahh, I thought that it was the other way around - probably not then.

GT-Rob

Thats odd they have one pointed to pub and one to sub. Yes it provides some load balancing, and I know you are on some older software/hardware, but unless you are in the 1000s of phones I wouldn't worry about and just point to the sub as your primary, and pub as your secondary in case its down. In a perfect world, your pub doesn't do any call routing, and a couple subs do all the heavy lifting. Not that it should 'break' anything this way though, unless like you say there are replication issues.


Im not familiar with 4.x, but where ever they hide 'reporting' (maybe under serviceability?), you should be able to generate a DB replication report, just to see wheres it at.



I didn't really read the other thread which sounds this is getting into, but feel free to draw a diagram/more detailed information and maybe we can spot the issue or at least ask you better questions to get to the root of it.

chmorin

The only differences between the two gateway configurations is for outbound calls.

The is the one that is not routing the particular number:


This one will route the particular number:


And here is the result of the dialed digit analyzer:



I'm reading my butt off in my CCVP books but still can't find a possible solution. This is the only discrepancy I have been able to find. Am I on to anything?

pitviper

Are they both terminating PRIs? If so, you can try running a "debug isdn q931" on the bad gateway and make a call to the number in question (be sure to enable terminal monitor if connected via telnet/ssh).

chmorin

pitviper wrote: »

Are they both terminating PRIs? If so, you can try running a "debug isdn q931" on the bad gateway and make a call to the number in question (be sure to enable terminal monitor if connected via telnet/ssh).

Maybe you could help me make heads or tails of the output:

XXXX-C2851#debug isdn q931
debug isdn q931 is              ON.
XXXX-C2851#
*Sep 22 14:01:12.809: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x1465
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98397
                Exclusive, Channel 23
        Display i = 0xB1, 'XXX XXXX'
        Calling Party Number i = 0x0081, 'XXXXXXXXXX'
                Plan:Unknown, Type:Unknown
        Called Party Number i = 0xA1, '1877XXXXXXX'
                Plan:ISDN, Type:National
*Sep 22 14:01:12.885: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x9465
        Channel ID i = 0xA98397
                Exclusive, Channel 23
*Sep 22 14:01:13.749: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x9465
        Cause i = 0x8281 - Unallocated/unassigned number
*Sep 22 14:01:13.821: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8  callref = 0x1465
*Sep 22 14:01:13.845: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x9465un all
All possible debugging has been turned off
XXXXX-C2851#

EDIT:

If it helps, here is the output of a working one:

ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x6A05
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98396
                Exclusive, Channel 22
        Display i = 'XXX XXXX'
        Calling Party Number i = 0x2181, 'XXXXXXXXXX'
                Plan:ISDN, Type:National
        Called Party Number i = 0x80, '1877XXXXXXX'
                Plan:Unknown, Type:Unknown
ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0xEA05
        Channel ID i = 0xA98396
                Exclusive, Channel 22
ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd = 8  callref = 0xEA05
        Progress Ind i = 0x8A81 - Call not end-to-end ISDN, may have in-band info
ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8  callref = 0xEA05
ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x6A05
ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x6A05
        Cause i = 0x8090 - Normal call clearing
ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8  callref = 0xEA05
ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x6A05

laidbackfreak

Just at a quick glance I see this :-

"*Sep 22 14:01:13.749: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x9465
Cause i = 0x8281 - Unallocated/unassigned number"

This error code is Cause i = 0x8281 - Unallocated/unassigned
number. Meaning: The switch receives the ISDN number in the incorrect
format.


Also you plans are different ?

pitviper

Yeah, the telco switch (fist 2 digits in the code "82") is rejecting it - Are both PRIs with the same carrier? If so, try matching up the plan/type settings on the gateway.

chmorin

pitviper wrote: »

Yeah, the telco switch (fist 2 digits in the code "82") is rejecting it - Are both PRIs with the same carrier? If so, try matching up the plan/type settings on the gateway.

I will check this tomorrow. Thank you for your assistance.

chmorin

It seems they do have different providers. We opened a ticket with them intially but they said it was not on their end and that they don't receive a call. Well they wouldn't when they don't know where to route the call.

Time to open another ticket with them. Thank you so much for your help!