Multiple Device Pools, Single SIP Trunk

[IT Service Desk]

Hi, I was hoping someone can shed some light on this. I am not an IPT engineer.  We are putting in a new CUCM 10 but the person who started this is no longer here and am just trying to pick up the pieces left behind.  Thank you in advance.

Question -

Ignoring for now any E.911 stuff... Can 2 device pools make outbound calling against a single SIP trunk (1 IP address)?  Office1 has a pub/sub and a single SIP trunk. Office2 has neither. We wanted two separate device pools. But the SIP trunk (found under Device | Trunk) can only be associated with a single DP.

We use an MPLS network dedicated to voice. The service provider is able to force inbound calls for both area codes to that SIP trunk.  I guess my problem is on the outbound.

If it is possible, how do we make this happen?  If not, does that imply that both offices must be in the same DP?

Thanks.

[Brandon Pierce]

Your NY_SIP SIP trunk doesn't have "Media Termiantion Point Required" checked does it?  I'm trying to figure out why you are burning out and throwing a 47 for resources not available. I mean, I guess you could just put everything in Device Pool1, I'm not sure why there are two if you arn't segmenting anything with resources outside of NY, unless for some reason NJ just had to have it's own set of resources and couldn't touch anything else NY had.

[IT Service Desk]

Sorry, bad browser refresh. Your previous message re: PCMU and stuff didn't appear until my last refresh.  Most output is similar to yours with slight variations.  But this PCMU thing is there.

Lastly, yes, the trunk has "Media Termination Point Required" checked ON.  Is this my problem?  Should this be unchecked?  If so, it looks like I can save and reset but that would drop any existing calls or no?  While this is being tested, we rolled this out to a handful of users already so a bit hesitant to restart/reset anything mid-day.

RE: MTP, I see that I have two MTP resources.

• MTP_2 with IP addy of pub but showing registered to sub.
• MTP_4 with IP addy of sub and registered to sub.
• For now, it appears MTP_2 is set to one DP and MTP_4 is set to the other DP.

There are 2 MRGs for MTP setup.

• One MRG_MTP has MTP_2 selected.
• The other has MTP_4 selected.

There are 2 MRGLs.

• The one for NY includes both MRG_MTP's but it is ordered such that NY is listed first.
• The other is for NJ and includes both MRG_MTP's but is ordered such that NJ is listed first.
• In both lists, the MTP's are the last set in this top/down list.

As for why there are multiple device pools, I don't know.  Without being an ITP engineer and knowing what the previous co-worker did, I assumed it was for either of 2 reasons - that it had something to do with E.911 and/or that it had to do with the fact that NJ will later get its own subscriber and voice circuit and/or that NY will have slightly different configs on the phones themselves than NJ...

[Brandon Pierce · Accepted solution]

Not sure why MTP is checked as on...Is your CUCM SIP trunked directly to the provider or do you have a gateway that the CUCM sends traffic to then to the provider?  You really don't want to be invoking MTPs if you don't need to, and in your environment so far, I don't see a reason to be using them unless something else is going on.  Also, yes it will drop all calls upon a Trunk reset, I would do this after hours and then test the phones.

Let me think a bit on this and get back to you.  I got a feeling if I were sitting in front of the system I would have had this solved yesterday.

Edit: What device pool is the SIP trunk in?

[IT Service Desk]

SIP trunk is in office1's DP.  

My understanding is that CUCM points traffic to my voice router.  One of the router's interfaces is for the inside and the other for the service provider's side...

Thank you.  I owe you many beers...

[Brandon Pierce]

Stupid question, does the voice gateway know how to get to the NJ office for voice calls?

If you do a "debug ccsip mess" on the router, you will get output from calls traversing the gateway.  You could pull those logs and provide them, it would be useful information as well. Make sure to do this when you are doing a test call though, otherwise you will just get data from calls we don't need.

[IT Service Desk]

Yes. If I put a NJ phone into the NY device pool, outbound to the PSTN works fine.  Moreover, from the voice router, to confirm, I was able to ping back to NJ endpoint (the 7965 phone).

I ran the debug to output to "monitor".  I made 2 calls.  One with the phone in the NJ device pool (where it fails) and one with it in the NY device pool (success).  Not having "Beyond Compare", took a while to go thru the output each line at a time. Unfortunately, the 2 debugs are nearly identical. Just time stamps and process IDs and such are different until it gets to the point where it shows the same output as the RTMT re: 

CANCEL for reason Q.850 and cause 47.  

Tail end, I see the following in red. This is also nearly identical to the successful call. The successful one also posted the last line as a Disconnect Cause (CC) of 16 and (SIP) of 487.  Given that once the successful call went thru, I hung up prior to teh recipient's voicemail kicking in, that these 2 codes reflect the user hanging up...

*Apr 22 18:52:58.120: //4316/98315B000000/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x0x15791A08
State of The Call        : STATE_DEAD
TCP Sockets Used         : NO
Calling Number           : <10 digit number of test phone>
Called Number            : <11 digits of dialed number: 1+areacode+phonenumber>
Source IP Address (Sig  ): <IP address>
Destn SIP Req Addr:Port  : <IP address>:5060
Destn SIP Resp Addr:Port : <IP address>:5060
Destination Name         : <IP address>

*Apr 22 18:52:58.120: //4316/98315B000000/SIP/Call/sipSPIMediaCallInfo:
Number of Media Streams: 1
Media Stream             : 1
Negotiated Codec         : g711ulaw
Negotiated Codec Bytes   : 160
Nego. Codec payload      : 0 (tx), 0 (rx)
Negotiated Dtmf-relay    : 6
Dtmf-relay Payload       : 101 (tx), 101 (rx)
Source IP Address (Media): <IP address>
Source IP Port    (Media): 25134
Destn  IP Address (Media): <IP address>
Destn  IP Port    (Media): 15182
Orig Destn IP Address:Port (Media): [ - ]:0

*Apr 22 18:52:58.120: //4316/98315B000000/SIP/Call/sipSPICallInfo:
Disconnect Cause (CC)    : 16
Disconnect Cause (SIP)   : 487

[Brandon Pierce]

Out of curiosity, swap out the MTP order for the MRG associated to Office2.  If it fails still, then we got something else going on.  I'm starting to draw a blank outside of media resource issues since that is the only thing different. 

[IT Service Desk]

Shoot. Tried that, moved the test phone back to the NJ device pool, the phone reloaded and still the same result.  I get a fast busy.

At some point, I realize (if this thing continues to fail), I need to get outside help from a source (e.g., TAC) that can actually view our configuration and troubleshoot.  I assume it's not easy for you to do this thru a forum.  So - I appreciate all the help and guidance you've provided thus far.  Anything else you can think of, I'm all ears.  If you can't do much more (given this is being done thru a public forum and you can't see my setup), let me know and I'll stop bugging you through this post...

Thanks again, man.

[Brandon Pierce]

At this point, the data that needs to be looked into might be sensitive from your perspective as we need the full SDL logs to see everything that goes on with a given phone trying to call from that site.  TAC would be the "safe" choice since it wouldn't be a public thing.  Some are comfortable posting detailed logs some arn't.  It's up to you though.  Here is a page of someone having the same problem:

https://supportforums.cisco.com/discussion/11185736/cause-code-47-errors-cdr-resource-unavailable-unspecified

I still think it has something to do with your call setup and either the ITSP or gateway/CUCM conversation is kicking it back for one reason or another.  Code 47 is almost always media resources/call setup issues and I am limited from a forum perspective on helping.  Usually issues like this never go this deep without an obvious cause from either a misconfiguration or bug.  Without seeing the entier config myself, can't do much.  Wish I could help more, but without detailed logs from RTMT and go line by line I couldn't help much more.  I do however, hope you post back the solution if you don't decide to post logs here for review.

[IT Service Desk]

Thanks.  Will do.  Will read up on the other link and see what I can fish around from here.  If I end up deferring to TAC, I'll be sure to follow up with a post.  

[Vivek Batra]

Excellent work Brandon... (+5)

[IT Service Desk]

SIP trunk is in office1's DP.  

My understanding is that CUCM points traffic to my voice router.  One of the router's interfaces is for the inside and the other for the service provider's side...

Thank you.  I owe you many beers...

[Vivek Batra]

Apart from excellent information shared by Brandon so far, please check the following thread which may give you fair idea about working of SLRG;

https://supportforums.cisco.com/discussion/12389856/local-route-groupquery

[IT Service Desk]

Hi Brandon, sorry I hit "Report" by accident instead of Reply. I did an Unreport. :-)

Within both Device Pools I see "Local Route Group Settings" and the Standard Local Route Group is set to < None > on both.

Sorry, hopefully last set of questions and will mark this as answered/correct.

1. Given the Device Pools show < None > for the above, does this mean, while the guy defined some SLRG, that I'm not actually using them for Device Pools?

2. Given that my Route List shows my RG1 as the top, does that mean it gets processed first (before the SLRG)?  If so, does that effectively mean I'm not really using SLRG?

3. But my Route Pattern shows that outbound calls should go thru the SLRG.

Sorry, very confused. I wish this were an ASA or something. Just easier for me... 

Thank you.

[IT Service Desk]

Brandon, this fixed it.  I removed the MTP required setting within the trunk's configuration.  After restarting the trunk, everything was good.

Thanks.