Just “Because the second BRI use line : 0537635777” it doesn’t by magic use that for egress calls when you call from the DN (999) that belongs to this BRI. You have to create the needed configuration for this in CUCM.
What you ask is absolutely possible. I previously described the configuration you need and what you have is not it. You have to create configuration in CUCM to send calls out the appropriate BRI circuit based on the DN that makes the call. Create something like this.
- Create RG1 that has GW1 as first and GW2 as second option.
- Create RG2 that has GW2 as first and GW1 as second option.
- Phone1 -> put in DP1, on it set RG1 as SLRG on the DP.
- Phone2 -> put in DP2, on it set RG2 as SLRG on the DP.
- Create a RP for calls to PSTN that uses SLRL as the RL.
There are other options for how achieve this, but this would be the way to use the most up to date style of configuration. For additional details on how this works have a look at this post, https://www.uccollabing.com/configuring-standard-local-route-group-cucm/
I updated my reply from yesterday with more detailed information on what you’d need. Please have a look at it.
If you look in more detail in the debug you’ll see that the calling number is translated in the GW.
Before translation
Dec 23 11:29:26.227: //-1/8034971B1B00/CCAPI/cc_api_display_ie_subfields:
cc_api_call_setup_ind_common:
cisco-username=
----- ccCallInfo IE subfields -----
cisco-ani=999
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=0638884592
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFFFFFFFFFF
cisco-rdn=
cisco-rdntype=-1
cisco-rdnplan=-1
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0After translation
Dec 23 11:29:26.234: //197/8034971B1B00/CCAPI/ccCallSetupRequest:
Calling Number=0537635777(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=0638884592(TON=Unknown, NPI=Unknown),
Redirect Number=, Display Info=
Account Number=, Final Destination Flag=TRUE,
Guid=8034971B-3831-9148-1B00-6C010AD41606, Outgoing Dial-peer=6
Dec 23 11:29:26.234: //197/8034971B1B00/CCAPI/cc_api_display_ie_subfields:
ccCallSetupRequest:
cisco-username=
----- ccCallInfo IE subfields -----
cisco-ani=0537635777
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=0638884592
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFFFFFFFFFF
cisco-rdn=
cisco-rdntype=-1
cisco-rdnplan=-1
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0As I wrote before, if it’s still not what is presented as the calling number on the receiving end the calling number is changed by the telco. You’d have to discuss this with them to find out if they have the option to let the calling number pass untouched. If not you'd have to do good with that you can get the correct calling number if the call egress out via the circuit where the phone number resides.
