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 described below.
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 6.4, “Local Number Porting” chapter.
- If it was ported, Sipwise C5 applies the LNP Rewrite Rules to the called number.
- Based on the priorities of peering groups and peering rules (see Section 5.6.2.3, “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.