Re: Problem SIP TRUNK between two cucm

kingstdz · ‎09-25-2023

Hi

we have two cucm A and B, each one is on site, connected by wan ip

we have configured sip trunk on each cucm A and B with ip up and full service

on site B call site A, and other can't , with cisco TRM we have seen that site call to other site no use sip trunk defined that why site A no call site B.

Site A use route pattern 2370xxxx with RL-TEST, and RL linked to RG-TEST linked to sip trunk defined (with ip cucm B).

Please any help i ll apreciate it.

thanks

Maren Mahoney · ‎09-25-2023

If the SIP Trunk is up and in Full Service, but calls are successful in only one direction, the question I would ask next is if both trunks have a correct Inbound CSS.

If so, the next question would be if any digit manipulation is happening (or needs to happen) in the direction that the call is failing.

Maren

Ibrahim AlQumairi · ‎09-25-2023

Please use the CUCM Dialed Number Analyzer (DNA) tool at Site B to troubleshoot the call flow. The output of the DNA tool may reveal any missing or incorrect configuration elements.

Additionally, please collect the SIP logs for the call and post them here so that we can further analyze the call path from Site B to Site A.

Nithin Eluvathingal · ‎09-25-2023

If i understood correctly, your problem is that you are not able to make extenions calling between two site using a SIP trunk you created recently.Here mentioned below are few things you must check.

As @Maren Mahoney mentioned, check if the trunk has CSS that can reach dialed extensions.
Check the RP Partition, make sure the RP is accessible for the phones
@Ibrahim AlQumairi Run DNA for both phone and trunk, Dialed Number Analysis will show the call flow, on the result if you see blocked pattern, you must check the CSS and Partitions: Analysis > Trunks & Analysis > Phones
If all above mentioned are good, then you need to collect logs from CUCM. Share it with us as we can help you troubleshooting.

kingstdz · ‎09-26-2023

thanks for yours replys

Results Summary
- Calling Party Information
  - Calling Party = 6001
  - Partition =
  - Device CSS =
  - Line CSS =
  - AAR Group Name =
  - AAR CSS =
- Dialed Digits = 23503424
- Match Result = RouteThisPattern
- Matched Pattern Information
  - Pattern = 23503424
  - Partition =
  - Time Schedule =
- Called Party Number = 23503424
- Time Zone = Etc/GMT
- End Device = RL_TEST
- Call Classification = OffNet
- InterDigit Timeout = NO
- Device Override = Disabled
- Outside Dial Tone = NO
Call Flow
- Route Pattern :Pattern= 23503424
  - Positional Match List = 23503424
  - DialPlan =
  - Route Filter
    - Filter Name =
    - Filter Clause =
  - Require Forced Authorization Code = No
  - Authorization Level = 0
  - Require Client Matter Code = No
  - Call Classification =
  - PreTransform Calling Party Number = 6001
  - PreTransform Called Party Number = 23503424
  - Calling Party Transformations
    - External Phone Number Mask = NO
    - Calling Party Mask =
    - Prefix =
    - CallingLineId Presentation = Default
    - CallingName Presentation = Default
    - Calling Party Number = 6001
  - ConnectedParty Transformations
    - ConnectedLineId Presentation = Default
    - ConnectedName Presentation = Default
  - Called Party Transformations
    - Called Party Mask =
    - Discard Digits Instruction = None
    - Prefix =
    - Called Number = 23503424
  - Route List :Route List Name= RL_TEST
    - RouteGroup :RouteGroup Name= RG-TEST
      - PreTransform Calling Party Number = 6001
      - PreTransform Called Party Number = 23503424
      - Calling Party Transformations
        External Phone Number Mask = Default
        Calling Party Mask =
        Prefix =
        Calling Party Number = 6001
      - Called Party Transformations
        Called Party Mask =
        Discard Digits Instructions =
        Prefix =
        Called Number = 23503424
      - Device :Type= SIPTrunk
        End Device Name = SIP-TRUNK-D
        PortNumber = 0
        Device Status = UnKnown
        AAR Group Name =
        AAR Calling Search Space =
        AAR Prefix Digits =
        Call Classification = Use System Default
        Calling Party Selection = Originator
        CallingLineId Presentation = Default
        CallerID DN =
      - Alternate Matches
        Partition :Name=
        Pattern
        Pattern = 2XXXXXXX
        Pattern Type = Enterprise
        Call Classification = OffNet
        CallManager Device Type = AccessDevice
        PatternPrecedenceLevel = PlDefault
        PatternRouteClass = RouteClassDefault

Maren Mahoney · ‎09-26-2023

Great! So that shows the the call should successfully flow out of the egress CUCM cluster. Now go to the DNA on the ingress (receiving) cluster and run another analysis.

Choose Analyzer > Trunks and select the trunk receiving the call. In the "Analyzer Input" section, enter "6001" in "Calling Party" and enter "23503424" in "Dialed Digits". This will perform an analysis of how the receiving CUCM cluster will process the call inbound. Let us know what you find.

Maren

DlccCisco · ‎09-26-2023

As you have signaled it in previous , the site B have css and partition and in site A no css and no partition thats why B call A and A no can call B, whats i must do in A to call B?

thanks

Maren Mahoney · ‎09-26-2023

Let me explain this way: Phone A in Cluster A will dial a number. The CSS of Phone A must have the Partition associated with the number in order to dial it. If the number dialed is a Route Pattern that will send the call over a SIP Trunk to another cluster, then assuming the trunk is in service the call will egress from Cluster A successfully.

Now the call will be received on Cluster B on the SIP Trunk that connects it with Cluster A. What we want is for the call to ring on Phone B on Cluster B. In order for this to happen, the SIP Trunk on Cluster B must have an Inbound Calling Search Space (as configured on the trunk on Cluster B) that has the Partition of the Directory Number on Phone B.

Both sides - the outbound call flow on Cluster A AND the inbound call flow on Cluster B - must be configured correctly for the call to be successful. The Dialed Number Analyzer output above shows that the outbound call flow on Cluster A should be successful. The next thing I would check, then, would be how Cluster B would process the call inbound.

I hope this explanation is helpful.

Maren

Nithin Eluvathingal · ‎09-26-2023

Hope this helps