Upper Registration
Upper Registration is the term used for the capability of OpenSBC to
proxy Registrations towards an upstream Registrar. In most cases,
SIP Networks already have an existing Registrar prior to the
deployment of a Border Controller such as OpenSBC. For this reason,
it would not be practical to transfer the existing SIP accounts to
OpenSBC.
Upper Registration is the solution to this scenario. While it is
necessary that all SIP requests traverse OpenSBC for NAT continuity,
Registrations MAY be allowed to be relayed towards an upstream
Registrar while OpenSBC retains a copy of the AOR and masquerade on
behalf of the the UA that send the registration request.
Understanding Local and Remote Domain Concept in OpenSBC
To understand how Upper Registration works, it is important to
distinguish when OpenSBC processes a request as a local domain
request and when it is treated as a remote domain request.
Local Domain Requests - requests with a request-URI not resolving to
one of OpenSBC''s listener interface and port either via DNS host
lookup, DNS SRV lookup or in raw IP Address form.
Remote Domain Requests - requests that, when Resolved, points to an
address and port tuple other than the ones listed as a listener
addresses of OpenSBC.
If REGISTER requests hits OpenSBC and OpenSBC is in either Full Mode
or B2B Upper Reg Mode the following steps would be followed:
1. OpenSBC checks if the request-URI is bound to a local or a
remote domain.
2. If the request is bound to a local domain ( request-URI resolves
to OpenSBC listener address ), OpenSBC will then check if the to-URI
resolves as local domain either in IP address from or via DNS
resolution. If both criteria is true then OpenSBC will
authenticate the REGISTER request against the accounts configured in
the "Local Domain Accounts" section. In this case, OpenSBC takes
the role of the Registrar.
3. If OpenSBC sees that the request-URI or the to-URI resolves to
an external address, then it checks if an upstream registrar route
is available in "Upper Registration Routes".
Upper Registration Route Example Entry:
sip:*@interop.opensipstack.org sip:interop.opensipstack.org
To explain further what the above entry means
**
sip:*@interop.opensipstack.org ** - This is a wild card match
filter for the to-URI of a REGISTER hitting OpenSBC
** sip:interop.opensipstack.org ** - This is the address of the
upstream registrar.
CAVEAT: Take note that if the request-URI or the to-URI resolves to
OpenSBC either in IP address or as a result of a DNS resolution,
upper registration routes will not be checked even if you have
existing entries for to To-URI. This is a common mistake that
continously appears in the opensipstack-devel mailing list.
4. If a route to an upstream registrar exists, OpenSBC will change
the Contact-URI of the REGISTER request to point to the address of
OpenSBC before sending the request to the upstream registrar. This
is called contact hijacking in OpenSBC lingo. The purpose of this
is to always let calls towards the registering UA to pass through
OpenSBC to assure proper NAT traversal. As far as the upstream
registrar is concerned, the UA that just registered to it is
OpenSBC. OpenSBC stores the original contact before it reqrites
the contact address. This would enable OpenSBC to properly route
requests bound to the UA in the future.
A Real Life Example
OpenSBC Address: 10.0.0.1:5060
Upper Registrar Address: 10.0.0.2:5060
Upper Registar FQDN: sip:interop.opensipstack.org
Register sent by the UA towards OpenSBC
REGISTER sip:10.0.0.1:5060 SIP/2.0
From: "Foo" ;tag=tag1234
To: "Foo"
Contact: "Foo"
Via: SIP/UDP sip:10.0.0.3:5060;branch=branch1234
Content-Length: 0
When this request hits opensbc, OpenSBC will resolve the to-URI to
10.0.0.2:5060 and thus would treat it as remote domain request.
Since there is a route entry in "Upper Registration Route" for an
upstream registrar:
sip:*@interop.opensipstack.org sip:interop.opensipstack.org
OpenSBC will enable upper registration for this request and hijack
the contact address.
REGISTER sip:10.0.0.1:5060 SIP/2.0
From: "Foo" ;tag=tag1234
To: "Foo"
Contact: "Foo"
Via: SIP/UDP sip:10.0.0.1:5060;branch=branch5678
Via: SIP/UDP sip:10.0.0.3:5060;branch=branch1234
Content-Length: 0
