[RESOLVED] PJSIP partitioning endpoint selection

I have an Asterisk 13.1-cert2 installation with PJSIP 2.4.5 and multiple PRI interfaces. I have a requirement of supporting overlapping dialplans to/from each PRI interface back to/from a Cisco Unified Communications Manager. I would like to do a 1:1 mapping of a PJSIP trunk to a PRI interface in both call directions (very basic TMD/SIP gateway for multiple PRIs with no digit manipulation in Asterisk).

Asterisk is configured to send calls from each PRI to the CUCM server sourcing from different IPs. This allows CUCM to know what PRI the call came from without an issue. However when sending calls from CUCM to Asterisk I’m running into an endpoint identification issue. After looking through debugs it appears when PJSIP tries to determine a source endpoint it does filter endpoint selection based on the ingress network binding. This results in an issue where same context being selected no matter what transport interface CUCM. Is there a way to partition out endpoints based on their network binding or make a single IP address into multiple endpoints?

Goal on one Asterisk installation:
SIP call from (CUCM) to (Asterisk transport1) > go into context1 > dial PRI 1
SIP call from (CUCM) to (Asterisk transport2) > go into context2 > dial PRI 2

I’m also open to alternatives solutions. Here is what I’ve considered/eliminated thus far:

Source from differnt IPs. You can’t add additional IP addresses to a CUCM server.
Use UDP and make the endpoint match both IP and port. The identify configuration in PJSIP doesn’t support matching source port numbers.
Prefix a digit that maps to a specific PRI when egressing CUCM. Pretty much, I’d just prefer not to do this. Seems clunky / not pretty when scaled.
Install multiple instances of Asterisk, one per PRI. Again seems clunky / ugly to scale.

I appreciate any assistance.

Based on what you are trying to do and what is available I think your easiest option really is the prefix a digit method. Without code modifications, or adding your own endpoint identifier, the existing options just won’t work to that granularity.

Thank you jcolp for the reply. Turns out I was over complicating it. I solved it in dialplan with an intermediary context that looks up what IP it came in on and then forwards to the appropriate context.

Glad to hear it! I forgot we had all sorts of information available to the dialplan.