Trust Relay Point (TRP) and Cisco Unified Border Element (CUBE)

[NICNGUYEN]

We would like to use a two features Trust Relay Point (TRP) and a Cisco Unified Border Element (CUBE) co-resident on a same router ISR 4431.

Does anyone know if there are any limitation and/or impact (CPU, RAM) ? Is there any documentation available regarding TRP and CUBE coresidency ? 

[Jonathan Schulenberg]

TRP is just an IOS SW MTP. The SCCP and CUBE processes are certainly capable of running on the same box but MTPs, regardless of where they are in the call path, can create unintended issues; they’re an extra thing to (re)negotiate and have their own limitations.

If I may ask: why do you want to use a TRP? I haven’t heard someone talk about that feature in probably a decade. 

[NICNGUYEN]

We want to use the TRP as a voice proxy to simplify the way we need to manage the security on ours firewalls. That's why we would like to keep using  TRP, but as we also want to enable Network Based Recording (NBR) on the same ISR4431 router we woud need to enable the border element (CUBE) feature as well, hence the question about co-residency.

[b.winter]

Per default, CUBE acts as a "voice proxy" (never heard of this term before), because it's a SBC (session border controller).
The primary tasks of an SBC is to split and hide networks of each other.
That includes (besides several other typical features), that the SBC per default terminates both call legs, which means the media goes through the SBC (technical term "media flow-through"). Maybe you should go back to basics about how SBCs work.

You don't need a TRP or MTP on the same device for that.

[Jonathan Schulenberg]

That's only true for trunk-side calls CUCM sends to CUBE though. Anything else (e.g. calls amongst IP Phones, to voicemail, etc.) would not be proxied unless you require that they use a TRP (MTP). That's the original intended use of the TRP, actually: force all media (not signaling) through a specific IP to simplify network segmentation ACLs and QoS classification & marking. The OP has the right idea; it's just rare to see.

As for NBR: invoking a TRP does not allow you to utilize CUBE features for that same call unless CUCM also sent that call to CUBE via a SIP trunk. In other words, internal calls amongst IP Phones would not be able to invoke NBR on the router but an off-net call from CUCM through CUBE to the PSTN would. Also, NBR is an example of where the TRP (MTP) can begin to complicate things. IIRC, an IOS MTP supports a maximum of five RTP streams per-call (I looked but was unable to find supporting documentation). An audio-only call with NBR enabled is four streams; however, video, BFCP, FECC, etc. would all exceed that limit. I can't remember if the call fails at that point or just those extra media capabilities don't work.

[b.winter]

@Jonathan Schulenberg You are right basically, but nobody was talking about IPphones, voicemail and other stuff.
The original poster wanted to use a CUBE and TRP on the same device, so in principle 2 times the same function of media-termination.
But maybe @NICNGUYEN could explain the complete setup a little bit more.
For what purpose do you use the CUBE? Only for connection towards a SIP-Provider? Or as a demarcation / connection point between to networks / PBX? ...