Figure A.1. General Call Setup
Sipwise C5 performs the following checks when processing a call coming from a
subscriber and terminated at a peer:
Checks if the IP address where the request came from is in the list of trusted
IP addresses. If yes, this IP address is taken as the identity for
authentication. Otherwise, Sipwise C5 performs the digest authentication.
When the subscriber is authorized to make the call, Sipwise C5 applies the Inbound
Rewrite Rules for the caller and the callee assigned to the subscriber (if any).
If there are no Rewrite Rules assigned to the subscriber, the ones assigned to
the subscriber’s domain are applied. On this stage the platform normalises the
numbers from the subscriber’s format to E.164.
Matches the callee (called number) with local subscribers.
If it finds a matching subscriber, the call is routed internally. In this
case, Sipwise C5 applies the Outbound Rewrite Rules associated with the callee (if
any). If there are no Rewrite Rules assigned to the callee, the ones assigned to
the callee’s domain are applied.
If it does not find a matching subscriber, the call goes to a peer as
Queries the LNP database to find out if the number was ported or not.For details
of LNP queries refer to the Local Number Porting
Section 5.5, “Local Number Porting” chapter.
If it was ported, Sipwise C5 applies the LNP Rewrite Rules to the called
Based on the priorities of peering groups and peering rules (see
Section 126.96.36.199, “Routing Order Selection” for details), Sipwise C5 selects peering groups for
call termination and defines their precedence.
Within every peering group the weight of a peering server defines its
probability to receive the call for termination. Thus, the bigger the weight of
a server, the higher the probability that Sipwise C5 will send the call to it.
Applies the Outbound Rewrite Rules for the caller and the callee assigned to
a peering server when sending the call to it.