Working on a BCM50 running 6.0.2.05.237. It is licensed for 4 SIP GW trunks; all 4 SIP trunks are in pool BlocA. We already have SIP trunking working perfectly between it and another BCM.
Now I want to peer it with a second remote system, also via SIP. This was relatively straightforward and I also have it working. I created a second route pointed at the same pool (perhaps not strictly necessary and probably could've re-used the same route for the 1st BCM, but oh well), added a second dest code pointing at that route w/ zero absorbed digits, and then added the second peer to the IP routing table using the dest code as the destination digits. Bam.
So that works great, and the remote system is also configured appropriately, and incoming and outgoing calls between the systems are all working.
Here's the problem: I want to ensure that there are always X number of channels available to each peer, for either incoming or outgoing calls. So for example, I have a BCM peered via SIP with two other BCMs, and a total of 4 SIP trunks on the main BCM. I want 2 of those trunks to be dedicated to one peer (incoming or outgoing), and the other 2 to be dedicated to the second peer (also incoming or outgoing), so that I can always be guaranteed a minimum number of available trunks to or from either peer.
Now, I believe that this is easy enough to do for outbound: I'd just take 2 of the SIP trunks, assign them to, say, pool BlocB, and then change the new route to point at BlocB. Unfortunately, as far as I can tell, for incoming SIP calls, the BCM sees all SIP channels on the system the same way it would see multiple channels belonging to a single PRI. So if none of the SIP trunks are in use, and an incoming call comes in, it ALWAYS occupies SIP trunk #1, regardless of which peer the call came from. This is no good: if 2 incoming calls come from peer #2 and occupy the first 2 SIP trunks, and someone wants to make an outbound call to peer #1, there are going to be 0 SIP trunks belonging to BlocA left to seize for that call.
This is stupid.
I have to think that there's gotta be a way with VoIP trunks to somehow emulate 2 physical banks of channels, where inbound calls from one peer always show up on SIP 1 and 2, and calls from another peer on SIP 3 and 4. I don't see a way to do this, though: the only place to reference the IP addresses of the peers is in the Routing Table for IP Trunks, and that only deals with outbound. I can't find anyplace where I can tell the BCM that these SIP trunks/channels belong to this peer for incoming calls. It just seems to be a free-for-all.
What, if anything, am I missing?
Thanks!!
-- Nathan
Now I want to peer it with a second remote system, also via SIP. This was relatively straightforward and I also have it working. I created a second route pointed at the same pool (perhaps not strictly necessary and probably could've re-used the same route for the 1st BCM, but oh well), added a second dest code pointing at that route w/ zero absorbed digits, and then added the second peer to the IP routing table using the dest code as the destination digits. Bam.
So that works great, and the remote system is also configured appropriately, and incoming and outgoing calls between the systems are all working.
Here's the problem: I want to ensure that there are always X number of channels available to each peer, for either incoming or outgoing calls. So for example, I have a BCM peered via SIP with two other BCMs, and a total of 4 SIP trunks on the main BCM. I want 2 of those trunks to be dedicated to one peer (incoming or outgoing), and the other 2 to be dedicated to the second peer (also incoming or outgoing), so that I can always be guaranteed a minimum number of available trunks to or from either peer.
Now, I believe that this is easy enough to do for outbound: I'd just take 2 of the SIP trunks, assign them to, say, pool BlocB, and then change the new route to point at BlocB. Unfortunately, as far as I can tell, for incoming SIP calls, the BCM sees all SIP channels on the system the same way it would see multiple channels belonging to a single PRI. So if none of the SIP trunks are in use, and an incoming call comes in, it ALWAYS occupies SIP trunk #1, regardless of which peer the call came from. This is no good: if 2 incoming calls come from peer #2 and occupy the first 2 SIP trunks, and someone wants to make an outbound call to peer #1, there are going to be 0 SIP trunks belonging to BlocA left to seize for that call.
This is stupid.
I have to think that there's gotta be a way with VoIP trunks to somehow emulate 2 physical banks of channels, where inbound calls from one peer always show up on SIP 1 and 2, and calls from another peer on SIP 3 and 4. I don't see a way to do this, though: the only place to reference the IP addresses of the peers is in the Routing Table for IP Trunks, and that only deals with outbound. I can't find anyplace where I can tell the BCM that these SIP trunks/channels belong to this peer for incoming calls. It just seems to be a free-for-all.
What, if anything, am I missing?
Thanks!!
-- Nathan
