Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Question on SIP AST Phone Survivability 1

Status
Not open for further replies.

bignose21

Programmer
Jul 4, 2003
2,223
GB
I just need a bit of help understanding the survivability of a SIP AST and call routing etc. with ESS and LSP for site(s)

In the User setup you config

Session Manager Tab you give it a Primary, Secondary and a Branch SM. give it an originating and terminating Application Sequence and a Home Location.
Communication Manager Tab has the Main CM, Type Endpoint, Extension, Set Type, Route Policy on CM for Optim trunk.

in the case of failure of main site so no Main CM & Primary SM, the sets will be active on the Secondary SM, I guess the application Sequence would have an application for the ESS in it also, but for the CM part how does it associate with the ESS or is that just on the app sequence?
 
ESS fails with a core SM
LSP fails over with a BSM.

For ess, your CM SIP entity in your app sequence needs to be in local hostname resolution of SMs networking configuration.

Pretend FQDN CM.procr maps to the IP of a main first and a ESS second - or vice versa. If you have a split brain scenario where both main CM and ESS are live, do you want a sip phone to go to the main or the ess? There are different reasons to pick one or the other, but that will drive your choice of which entity in the LHNR table goes first.

For LSP, once LSP kicks in, it overwrites every far end node name of every SIP sig group with the BSM IP. I can't remember if every LSP needs to be in LHNR or if the BSM just 'knows' based on a LSP going active on it.
 
So I think currently the SIP Entity has IP address of of the Main CM, so I would need to alter that to the FQDN and add that FQDN to the Local Host Name Resolution to first go Main and then ESS.
 
Yup.

Important to consider what you're failing over though. Probably main as first priority and ESS as second will suit you.

Unless you prefer that if DC2 goes live that everything process through DC2.

Do you want everything to "abandon ship" on DC1 as soon as all sites would be still together as a gang on DC2?
Do you want everything to "sink with the ship" on DC1 because one site flipped to DC2?

If you're not completely on Media Servers and have G450s, consider that the failover mechanism of primary search/total search is in "minutes". So, if Primary Search is 3 and Total Search is 10, there is a chance that a WAN outage at the site of 3 minutes 30 seconds causes the G450 to register to DC2 for a while. There's no way around the scenario where a WAN outage of (Primary Search time + between 1 and 59 seconds) causes the gateway to register to DC2.

It's usually best to have LHNR point to the main first, but your mileage and architecture may vary!
 
So DC1 is a duplex CM and DC2 is a Simplex ESS and then each site has at least 1 LSP (if say the site is across 3 comms rooms it would have 3 LSPs, and the G450's would be Main/ESS/1 LSP considered the main one for the site/LSP local to the Gateway).

They are in proper DC's as well so TBH never seen an outage on them yet. I think in this case if DC1 is available and one site or gateway flipped to DC2 it can go on its own, the sites are independent of each other mostly. We have no Media Servers as we have a ton of TDM so lots of G450/G430.
 
I have a question on the LHNR (session manager 8.1.2) so I have 2 SIP Entities to the CM a SIP Trunk TLS on port 5061, and an OPTIM TLS on port 5062.

In LHNR it wants the FQDN/IP Addr/Port/Priority/Weight/Transport, if I try to add for example

CM.domain.com / 1.2.3.4 / 5061 / 100 / 100 / TLS
CM.domain.com / 2.3.4.5 / 5061 / 200 / 100 / TLS
CM.domain.com / 1.2.3.4 / 5062 / 100 / 100 / TLS
CM.domain.com / 2.3.4.5 / 5062 / 200 / 100 / TLS

I would get an error for duplicate input for the host that say the 1st one clashes with the 3rd one, and the 2nd with the 4th.
 
Its ok think I just need to do this and update the SIP Entities accordingly

CM.domain.com / 1.2.3.4 / 5061 / 100 / 100 / TLS
CM.domain.com / 2.3.4.5 / 5061 / 200 / 100 / TLS
CM-optim.domain.com / 1.2.3.4 / 5062 / 100 / 100 / TLS
CM-optim.domain.com / 2.3.4.5 / 5062 / 200 / 100 / TLS
 
Do you have BSMs? I can't remember and I've never been heavy on branch implementation.

Are you all SIP phones?
Have you tested branch failover?

I would think the smartest thing/way they did it was that the BSM knows which phones are assigned to it and and it automagically uses the LSP for app sequencing once the LSP advertises it is active because of a gateway registration.

 
Very little IP at sites due to the environments at the sites, we do have BSM for the odd couple of sets that are there but as you can imagine they are the critical users. The phones are configured for the BSM as the survivable SM and I think the LSP gets the BSM IP from the Server Role page when you setup the LSP.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top