SM CM Trunk Group Selection

[vgjc]

Currently, our CM entity is configured with a CLAN for the IP address.
We have the same CM defined in other entity links with procr for the IP address - configured for AAM and AAC integration.
We also have several trunk groups defined in CM to SM - some with CLAN in the signaling group and some with procr.

When a SIP desk phone makes a call to a digital desk phone, what determines which CM trunk group handles the call?

We have found that it picks one of the CLAN trunk groups.

The application sequence which the SIP end points have for origination and termination is built with the CM entity which is using CLAN's.

We are trying to migrate procr and had issues during the first attempt.

We would like to configure test SIP phones to use one of the procr trunk groups when making the outbound calls.

We can control calls from the digital desk phone to the SIP desk phone by AAR analysis, and calls do work on the procr trunk group.

One thought is to create a new application which uses one of the CM entities with procr as the IP address. Can you configure multiple applications with the same CM System for SIP entity - one application has the CM entity with CLAN and the other has the CM entity with procr but both use the same CM System for SIP entity.

Thank you.

[mlombardi1]

You need different domains defined on the signaling groups to separate SIP traffic type (endpoints, trunks, etc.). I've tried to define multiple signaling groups with the same far-end node (SM) but using different ports and the behavior is inconsistent.

With multiple signaling groups for SM, CM6 uses the following algorithm for trunk selection:

• Start with lowest numbered signaling group
• Match on far end IP address
• If multiple matches, match domain contained in PAI header to far end IP domain on signaling group forms
• If multiple IP domain matches, select lowest number signaling group
• Match on blank domain
• Use lowest number signaling group

CM compares the domain in the PAI header of the inbound request to the signaling groups. The R-URI and To headers can use the CM authoritative domain (assigned to procr); it's just the PAI that needs differ.

[boehm8]

Hi mlombardi1,

this got some light in my darkness but anyway not enough. We have different trunks from the ACM to the Session Manager and the traffic from the ACM to SM is working as expected. But I do not understand how exactly the logic is the other way arround. I have the same Near-end Node Name and the same Far-end Node Name in all signaling Groups but I have different Far-end Domains. Also I have the same different Domains in the session Manager. (the different Domains are like xyz.com and ab.xyz.com)or do I Need completely differnt ones? I also tested that and I got no Connection with something like no authoritative Domain in the error message. Are yyou able to help me?

regards
Stephan