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 Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
ASM Failover Group
- Thread starter trilogy8
- Start date
Yes, it is separate. I've been lazy and never done FGDNs before - failover group domain names.
So, Avaya AST SIP phones - J/96xx/etc can register to 3 SMs simultaneously. Upon registering to a primary or secondary or survivable, those SMs send the whole list of SMs a phone should use - just like how CM sends the alternate gatekeeper list to a H323 phone based on what region it is in. That's all it is.
Failover groups are something you'd notice in a failover test. Those have a bit to do with phones, but also with trunks.
It lets you take a pair of SMs like sm1.lab.com and sm2.lab.com and put smclusterA.lab.com as a FQDN underneath which sm1.lab.com and sm2.lab.com live. Everything points to smclusterA.lab.com and gets directed to a SM underneath.
In terms of call processing, comparing it to CM, it gets you closer to being CM duplex instead of simplex CM with an ESS. So, both SMs are aware of all calls. Let's say a random analog Polycom phone on a G450 calls out a SIP trunk into a conference bridge. Let's say that call lasts 2 hours. Let's say SM1 died 20 minutes into the call. The call stays up, SM never handled the media anyway, and new calls set up just fine through SM2.
But you have session refresh timers
Every 15/30/60 minutes or whatever you're going to see (by default) the user agent client - the SIP thing that asked for service - so, your CM making the outbound call - send a refresh up to the PSTN. Thru Session Manager 2. As an in-dialogue message for an established call. If you have failover groups, SM2 will pass it up. If you don't, SM2 knows nothing about this reinvite for a session refresh for a call it doesn't know about and you'll quickly realize that long calls set up on SM1 eventually die with SM1 once the refreshes can't be done
So, Avaya AST SIP phones - J/96xx/etc can register to 3 SMs simultaneously. Upon registering to a primary or secondary or survivable, those SMs send the whole list of SMs a phone should use - just like how CM sends the alternate gatekeeper list to a H323 phone based on what region it is in. That's all it is.
Failover groups are something you'd notice in a failover test. Those have a bit to do with phones, but also with trunks.
It lets you take a pair of SMs like sm1.lab.com and sm2.lab.com and put smclusterA.lab.com as a FQDN underneath which sm1.lab.com and sm2.lab.com live. Everything points to smclusterA.lab.com and gets directed to a SM underneath.
In terms of call processing, comparing it to CM, it gets you closer to being CM duplex instead of simplex CM with an ESS. So, both SMs are aware of all calls. Let's say a random analog Polycom phone on a G450 calls out a SIP trunk into a conference bridge. Let's say that call lasts 2 hours. Let's say SM1 died 20 minutes into the call. The call stays up, SM never handled the media anyway, and new calls set up just fine through SM2.
But you have session refresh timers
Every 15/30/60 minutes or whatever you're going to see (by default) the user agent client - the SIP thing that asked for service - so, your CM making the outbound call - send a refresh up to the PSTN. Thru Session Manager 2. As an in-dialogue message for an established call. If you have failover groups, SM2 will pass it up. If you don't, SM2 knows nothing about this reinvite for a session refresh for a call it doesn't know about and you'll quickly realize that long calls set up on SM1 eventually die with SM1 once the refreshes can't be done - Thread starter
- #3
Would probably behoove me to create the group. Maybe misinterpreting, but for about 20 SIP users with the primary SM being sm1 and secondary sm2, I don't see simultaneous registrations. Only the one to the primary. Should I see the endpoint registered to both?
If they're Avaya SIP phones, yes.
Do you see "AST" ticked? That's a key part - it's PPM. Basically that's the application sequencing down to CM in the SM Profile/CM Endpoint Profile and having the SIP endpoint in off-pbx station-mapping point a trunk or AAR and point back to SM as private numbering
It's the thing that lets the phone login, subscribe to its feature packages and ask CM what's up. So, if CM has MWI ON for that phone, upon logging in, going through that flow is what tells the phone it should light its lamp and other things.
Do you see "AST" ticked? That's a key part - it's PPM. Basically that's the application sequencing down to CM in the SM Profile/CM Endpoint Profile and having the SIP endpoint in off-pbx station-mapping point a trunk or AAR and point back to SM as private numbering
It's the thing that lets the phone login, subscribe to its feature packages and ask CM what's up. So, if CM has MWI ON for that phone, upon logging in, going through that flow is what tells the phone it should light its lamp and other things.
jimbojimbo
Vendor
Failover Groups are for SIP trunking and not for SIP endpoints. There were too many caveats to really make them useful in previous releases. In Aura 8.0 there are a couple of interesting and separate features design for SIP endpoints. Clustered Session Managers and SIP Resiliency. Clustered Session Manager fixes the whole "I have to built out how many SIP trunks for DR" issue and SIP Resiliency is used to "rebuilt" the SIP signal connection to the endpoint.
- Status
Similar threads