CM SIP trunk limit 255 members but I have 300 SIP call paths, how make SM use 2 trunks to CM? 1

[rejackson]

We have our SIP implemented 2-3 years ago. We got 300 call paths from our carrier but the trunk configuration in CM to SM has a max of 255 members. It didn't bother me in the past but now I would like to make the whole 300 paths available between CM<>SM<>SBC. I figure I need another trunk on the CM side that I would add to the routes that point to the SM. I cannot figure out how to configure the SM side. I do not see any references to the members, channels, or whatever would set the capacity of the links. I think I need a new location to put under the existing entity or vice versa but not sure. I am also not sure how SM would know one link is full and another should be used since capacity is does mot appear to be defined.

Any assistance would be appreciated. I do not make a lot of changes in SM and the components seem to have a lot of circular references.

Step 1: Create "Domains" of type SIP (other routing applications are referring domains of type SIP).
Step 2: Create "Locations"
Step 3: Create "Adaptations"
Step 4: Create "SIP Entities"
- SIP Entities that are used as "Outbound Proxies" e.g. a certain "Gateway" or "SIP Trunk"
- Create all "other SIP Entities" (Session Manager, CM, SIP/PSTN Gateways, SIP Trunks)
- Assign the appropriate "Locations", "Adaptations" and "Outbound Proxies"
Step 5: Create the "Entity Links"
- Between Session Managers
- Between Session Managers and "other SIP Entities"
Step 6: Create "Time Ranges"
- Align with the tariff information received from the Service Providers
Step 7: Create "Routing Policies"
- Assign the appropriate "Routing Destination" and "Time Of Day"
(Time Of Day = assign the appropriate "Time Range" and define the "Ranking")
Step 8: Create "Dial Patterns"
- Assign the appropriate "Locations" and "Routing Policies" to the "Dial Patterns"
Step 9: Create "Regular Expressions"
- Assign the appropriate "Routing Policies" to the "Regular Expressions"

 

[kyle555]

Just build another sig/trunk group with the same parameters. SM doesn't care - it sends it to CM, not to any specific sig group.
CM will fill up the lowest numbered numerical sig group that matches everything first, and use the next after.
Just make sure to match the incoming digit treatment table, pub unknown and change your routes for outgoing to use both trunks as a choice.

 

[rejackson]

Thanks Kyle,

It sounds like magic on the SM side. I have a few follow ups to my question. The CM entity for the existing link is a CLAN. We are not on IP Proc. So the entity link references a specific IP address on the CM side. I am guessing that I need to create the new sig/trunk on the same CLAN? The CLAN handles registrations and I don't think it has a limit that affects the number of calls on the registered links for phones and trunks. Is that correct?

Since it is magic does that mean that nothing needs to be done on the entity link from SM<>SBC?

Thanks again
REJ

 

[kyle555]

Yup, you got it.

Though, if you actually plan on using all those SIP trunks I'd suggest moving them to procr. You might choke the IPSI with 500 calls worth of SIP messaging up on it and a busy port network.

 

[kyle555]

And it isn't magic! It's just how CM deals with getting around the 255 member limitation.

Page 17 of this doc explains that a bit better:

https://downloads.avaya.com/css/P8/documents/100057381

More than one signaling group may be administered to share a signaling connection with
exactly the same properties of:
● far-end node-name (fe-nn)
● far-end port (fe-pt)
● near-end node-name (ne-nn)
● near-end port (ne-pt).
This kind of administration supports more than 255 calls on the same SIP-based signaling
connection, where a signaling connection is defined as <near-end node-name, near-end port,
far-end node-name, far-end port>

 

[rejackson]

Yes I understood the CM side of it. By magic I was talking about SM not having any limit configured and CM could be changed without even telling SM. I am sure on a CM<>CM trunk both ends would need to be configured. Being pure IP SM appears to just open a connection and CM assigns it to a trunk member internally.

 

[kyle555]

That's right. SM don't care. It'll do bandwidth control, but as a SIP proxy and registration server, it isn't terribly concerned with all that stuff. It's only a signaling box and no media goes through it, so it doesn't have all that stuff.

 

[rejackson]

Kyle,

I got a chance to test this by configuring it as you said then busying the other CM<>SM trunk. Worked great. Only issue I had was needing to add the new trunk to the private numbering table so CM would send the extension to SM on the outgoing calls.

REJ