[SIPForum-discussion] Registrar forcer re-registration

[Mark Holloway]

The SBC in the secondary location should still have a way to reach the
primary feature server on a private network.  If you're losing the
public-facing side of the network on the primary SBC and users re-register
to the SBC in the second location, the SBC in the second location should
still be able to reach the primary feature server and update the SIP
registration information showing it coming from the secondary SBC.  The only
time you'd want the SBC talking to the standby feature server is if the
primary feature server is literally down.  

 

The gateway should have primary/secondary paths for SIP Invites so when the
SIP Invite from the gateway fails to the primary, it goes to the secondary
SBC, which already knows which feature server cluster to send the call to.  

 

Below you show this:

 

Situation is Gateway -> Feature Server -> Standby SBC

 

You should be peering your gateways with the SBC and not sending SIP Invites
directly to the feature server from the gateways.  

 

My guess is we're talking about two different types of architectures.  I'm
assuming your gateways are on the public side along with your subscribers.
The inside of your SBC network should use agent groups that always know
which servers are up or down.  Whether it's SIP Registration or Invites
coming from some public IP's, the SBC's would always know which feature
server is up to process the call.  That means regardless of which SBC is
being used on the public side, all the SBC's should attempt to talk to the
same feature servers in the same attempted order.  

 

 

From: Tyler Parkin [mailto:tyler at foxfam.com] 
Sent: Wednesday, January 16, 2008 7:21 PM
To: Mark Holloway; discussion at sipforum.org
Subject: Re: [SIPForum-discussion] Registrar forcer re-registration

 

Hi Mark,

 

Thanks for your quick reply.  Let me see if I can re-phrase what I'm trying
to resolve.

 

We have multiple SBC's on our network, with an active and standby in each
location, and our users targeted to an SBC node based on market.  If the UA
is set to register via a DNS SRV record, they will register with the proper
SBC for their region.  On failure, we can updated the DNS record to reflect
a standby node and new invites originating from the UA will be directed to
the standby node, then to the feature server/registrar, and from there out
one of our gateways.  In a failure situation, SIP -> PSTN is not an issue at
all due to DNS records an authenticated INVITE messages.

 

On register a UA REGISTER message is delivered to the SBC, which caches the
origin IP and call-id information, NAT's the IP, and then forwards the
registration to a Registrar/Feature Server.  The Registrar/Feature server at
that point has the user telno record pointing to the IP of the SBC's
private/internal side.  

 

In an outage situation where we lose an SBC node, we change the DNS SVR
record to a standby SBC node which does not have the cached NAT/IP/Call-ID
records and therefore the call fails.  Situation is Gateway -> Feature
Server -> Standby SBC which fails to find the entry for the destination
because that entry was created in an SBC node that would be down.

 

To get around that situation we would have to re-register the endpoints to
reestablish the cached entry (endpoint IP) in the standby SBC and Registrar.

 

To be clear, our current configuration includes an active and standby SBC
which share cached information.  The situation we're looking at is where we
lose an entire colo facility (active & standby).

 

Thanks,

 

Tyler

----- Original Message ----- 

From: Mark Holloway <mailto:mh at markholloway.com>  

To: 'Tyler Parkin' <mailto:tyler at foxfam.com>  ; discussion at sipforum.org 

Sent: Wednesday, January 16, 2008 8:43 PM

Subject: RE: [SIPForum-discussion] Registrar forcer re-registration

 

Depending on where the outage resides and whether you have geographically
diverse SBC's, your gateways should have the ability to point to two
different geographically located SBC's as primary/secondary or use DNS SRV's
with multiple A records.  If you only have one geographic location with an
SBC, the SBC should be configured to monitor your routing and application
server clusters on the protected side of the network so it can forward the
SIP invites to the active servers in the cluster where the users' SIP
registration lives.   

  

 

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of Tyler Parkin
Sent: Wednesday, January 16, 2008 5:40 PM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] Registrar forcer re-registration

 

Good evening,

 

I'm curious to know if there is a SIP method for a registrar to force (an
early) re-registration. 

 

Our network is pretty standard:

 

SIP UA -> SBC -> REGISTRAR

 

In an effort to minimize the effects of an outage event, identifying a
solution for SIP -> PSTN calls is easy.  However, PSTN to SIP calls is more
difficult unless the registration cache in both the SBC and the
Registrar/feature server are updated (due to endpoint IP NAT'ing).  To date,
our only solution has been to re-register the UA's, either via a SIP method
(preferred) or a script that logs into each UA and tears down the endpoint
and rebuilds it.

 

In reading the RFC's, I've been unable to find a SIP method that will force
a UA to re-register prior to reaching the normal expires value and thought
I'd bounce it off the community.

 

Thanks,

 

Tyler

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20080116/c7da6fb8/attachment-0002.html>