Call forwarding

PortaSIP supports several call forwarding modes; you can select a specific mode from the Forward Mode menu on the Call Features tab:

• Simple Forwarding is unconditional forwarding to a single phone number, pre-defined by the user.
• Follow-me allows you to specify multiple destinations for call forwarding, each of which is active in its own time period. You can also specify that multiple numbers be tried one after another, or that they all ring at the same time, or that they are tried, percentage-wise, depending on the total number of incoming calls.
• Forward to SIP URI allows you to specify not only a destination phone number but also an IP address for calls to be forwarded to. This is useful when calls have to be routed directly to an external SIP proxy.
• Advanced Forwarding adds a few extra options to those available in Follow-me mode, and also allows you to route calls to SIP URI. It thus represents a super-set of all call forwarding capabilities.

The follow-me feature allows you to receive calls even if your IP phone is offline at the moment. You can specify several alternative destinations for a single destination number (account). Follow-me is activated when:

• IP phone is offline (not registered).
• IP phone replies with an error code (e.g., the line is currently busy because you are making another call).
• No answer is received within a certain interval (usually 20 seconds) – the phone may be online but nobody answers, or there is a network outage.

For instance, if you do not pick up your IP phone (or the IP phone is unreachable due to a network error) the call would be forwarded to your home phone; if not answered within 30 seconds, it would be forwarded to your mobile phone, and so on. For each of these phone numbers, you can define the period when a given phone should be used; for example, calls should be forwarded to your home phone only from 8 in the morning until 9 in the evening.

• C wishes to call A. So he dials A’s phone number (since C is in the US, he dials it using the North American format, 2027810003).
• The call is routed through the telecom network to gateway GW-NY-01. When the incoming call arrives at the gateway (1), it is processed there in exactly the same way as a normal PSTN->SIP call: the number is transformed, the call is authorized in the billing engine (2), and the timer starts to measure the maximum call time allowed, based on A’s current balance (3).
• The call is sent to PortaSIP (4).
• PortaSIP receives the INVITE, but without authorization information. So the PortaSIP server performs authorization in the billing engine based on the IP address, and also requests billing-assisted routing (5).
• PortaBilling recognizes that the destination is an account with follow-me services enabled, and produces a special list of routes:
  • If the follow-me mode chosen is “When unavailable”, then a direct route to the account’s SIP UA is included as the first route in the list, with a default timeout.
  • A list of follow-me numbers is produced. If the current time falls outside the specified period for a certain number, it is removed from the list.
  • If the follow-me order is “Random”, then the list of phone numbers is shuffled.
  • The maximum call duration is calculated for each follow-me number, based on the balance and rates for the called account (A).
  • The resulting list of routes is produced and sent back to PortaSIP (6).
• PortaSIP tries the first route (7); if the call is not connected within the timeout interval, it moves to the next route (8), then to the next one (9), until either the call is put through or no more routes are left.
• If such a call was completed to follow-me number R (SIP account), then two CDRs will appear in the system: one for the call C->A (charged per the incoming rates for A) and the other for C->R (charged per the incoming rates for R).
• If the call did not originate in the PSTN network, but rather from user B’s SIP UA, two CDRs will likewise be generated. B will be charged for call B->A, while R will be charged for B->R (charged per R’s incoming rates).

The follow-me service can be recursive. Thus, A can forward calls from his SIP phone to B’s SIP phone; B, in turn, can forward calls from his SIP phone to C’s SIP phone, and C can forward to D’s SIP phone, etc. D can even forward calls to his mobile phone number. So, in the case of such a multi-hop follow-me (A->B->C->D->PSTN number), only two CDRs are produced (similar to a simple follow-me):

• A CDR for the caller (billed to A for the outgoing call, A->B).
• A CDR for the forwarder outside the network, e.g., the last SIP account in the follow-me chain (billed to D, A->PSTN).

You can define a follow-me list with several phone numbers, all of which will ring concurrently. The first one to answer will be connected to the incoming call.

You can also include your own phone number on the list of phone numbers for simultaneous ringing. Your IP phone will then ring together with the other phones (e.g., your home phone or cell phone) and you can answer either one of them. In this case, you are advised to modify the call processing so that it does not include the Ring action but starts immediately with Forward. Otherwise, the system will first ring only your IP phone and then ring both your IP phone and all the other phones.

In traditional call forwarding, you only specify a phone number where calls are sent using the currently available termination partners. This is very convenient for calls terminated to PSTN, since in this case PortaSwitch LCR, profit-guarantee, fail-over and other routing capabilities are engaged automatically. If you provide services such as DID exchange, however, calls must be forwarded directly to a large number of different SIP proxies belonging to your customers. In this case, for every account (DID) you simply define which phone number and IP address all incoming calls should be forwarded to.

In order to protect you from abuse of this service (e.g., a customer tries to set up call forwarding to somebody else’s network, then relays a storm of call attempts through your SIP server) it is only possible to use those SIP proxies, which are listed in the Permitted SIP Proxies customer information. If a customer who buys DIDs from you has two SIP proxies, you need to list each of those proxies in the Permitted SIP Proxies configuration. After that, your administrators (or the customer on his self-care pages) will be allowed to use these IPs in the SIP URI.

When a call is forwarded to an off-net destination, it is treated as two separate calls from a billing perspective. Thus, if party A (SIP account) calls party B, and B has follow-me set up for off-net destination C, the following will occur:

1. PortaBilling will check if A is authorized to call B and for how long (based on A’s rates and the funds available in A’s account).
2. If forwarding is currently active on B’s account, PortaBilling will check if B is authorized to call C and for how long (based on B’s rates and available funds).
3. After the call is completed, the two accounts are charged, and CDRs are produced accordingly: one for account A, for a call to destination B, the other for account B, for a call to an off-net destination C.
   • If the call did not originate from SIP account A, but rather from the PSTN network, then two CDRs will likewise be generated. B will be charged for both calls: one for PSTN->B (charged per the incoming rates for B), and another for B->C (charged per the outgoing rates for B).

For A, this call looks like any other call made to B. If B is a number in the US, it will look like a call to the US, and A will be charged according to US rates, even if the call was actually sent to a mobile phone in the Czech Republic. For B, the forwarded call is authorized and billed according to the same rules as a normal outgoing call from this account (or you can apply a different rate plan for forwarded calls). For instance, if B is allowed to make outgoing calls only to US&Canada, and tries to set up a follow-me number to India, the number will not be usable. If multiple follow-me numbers have been defined, each one will be authorized independently. So if B currently has $1 available, and this is enough to make a 5-minute call to the Czech Republic or a 3-minute call to France, the call will be automatically disconnected after 5 or 3 minutes, respectively.

Billing for calls forwarded to a SIP account differs from the above case, in which a call is forwarded to an off-net destination.

When a call is forwarded to a SIP account, it is still treated as two separate calls, from a billing perspective, although the logic is different. Let’s consider the following example: if account A calls account B, and B has follow-me set up for account C, the following will occur:

1. PortaBilling will check if A is authorized to call B and for how long (based on A’s rates and the funds available in A’s account).
2. If forwarding is currently active in B’s account, PortaBilling checks that B is not barred to call C (this restriction can only be based on B’s service features such as Call Barring, since B’s tariff does not influence calls forwarded to other SIP accounts) and also if C is authorized to receive the call and for how long (based on C’s incoming rates and the funds available in C’s account).
3. Then, after the call is completed, the two accounts are charged and CDRs are produced accordingly: one for account A for a call to destination B and the other for account C, for an incoming call from account B.
   • Note that intermediary forwarding accounts (account B in this example) are not charged because they don’t actually generate calls and their role (forwarding a call to another SIP account) doesn’t involve any costs for the service provider.
   • If the call did not originate from SIP account A, but rather from the PSTN network, two CDRs will likewise be generated. B will be charged for call PSTN->B (charged per the incoming rates for B), while account C will be charged for B->C (per the incoming rates for C).

When there is a limit set on forwarded calls for a product, customer or customer site, PortaBilling applies those limiting parameters based on the configuration of the account that is charged for the call.

Thus, if account B has follow-me set up for several off-net destinations and several calls arrive to B, PortaBilling checks its limit on forwarded calls when it authorizes the calls and then processes the number of calls that are either equal to or fewer than the specified limit value.

For example, when calls come into Mark’s SIP phone and he is not in the office, he wants them forwarded to both his mobile and landline numbers. Mark is allowed to receive calls at both numbers simultaneously (the limit on forwarded calls is set to 2.) So when Mark talks on his cell phone and a new call comes to his SIP phone, that call is forwarded to his landline number.

When follow-me service is recursive and a call is forwarded several times among several SIP accounts until it is finally forwarded to an external number (B–>C–>D–>PSTN), the last SIP account in the chain is the one charged for follow-me forwarding and PortaBilling considers what the forwarding limits are for this account (in this case, account D).

So let’s say that Ann, Joe, and Mark have follow-me service configured. When a call comes to Ann’s SIP phone and there is no answer, it is forwarded to Joe’s phone. If Joe is unavailable and does not answer the call, it is forwarded to Mark’s phone. But if Mark is busy talking on his cell phone, PortaBilling regards the number of allowed forwarded calls on Mark’s account (2), and therefore the call is forwarded to his landline number. After the call is finally answered, it is Mark’s account that is charged for the forwarded call.

In our example, if the administrator sets the value for the number of forwarded calls to 1, and a new call comes to Mark’s SIP phone while he is away and/or already talking on his cell phone, the call to the landline number is not forwarded.

PortaBilling only limits billable calls – calls for which PortaBilling produces xDRs and applies charges to an account. These are transferred calls (charged with the tariff matched by the TRANSFER access code), redirected calls (e.g., calls that arrive to an auto attendant from external networks) and calls forwarded to off-net destinations (charged with the tariff matched by the FOLLOWME access code). If a final forwarding destination is a SIP account, the limit on forwarded calls is not applied.

When calls are forwarded outside the system, each such call requires an exit point. Therefore, when an administrator limits the number of simultaneously forwarded calls, they define the number of exit points available for a single account.

When calls are forwarded among one or several SIP accounts, they do not leave the system, and, therefore, they require no exit points. Thus, forwarded on-net calls are not counted in terms of authorization when PortaBilling checks the number of available exit points and then verifies those limits.

Very often a company operating an PBX would purchase multiple phone numbers, all of which were to be routed to the company (e.g., the main office phone number is in the New York area, but the company also has an 1800 number and a number in the UK for their UK-based sales representative). In general, each additional phone number is provisioned as an account in PortaBilling, and then a corresponding SIP phone is registered to PortaSwitch using this account ID to receive incoming calls. But some PBXs (e.g., SPA-9000) can only register a single telephone number (account) with the SIP server. In this case, you may set up calls from additional phone numbers to be forwarded to the main account using the follow-me feature. For example, a PBX registers to PortaSwitch with account 12061234567; however, DIDs 18007778881 and 4412345678 must also be delivered to the PBX. So you would set up accounts 18007778881 and 4412345678 with follow-me to 12061234567. All calls will then be correctly routed to the PBX; however, since they all arrive to the PBX as calls to 12061234567, calls to different DIDs cannot be distinguished (e.g., if a customer originally dialed the 1800 number, he should be connected to general sales, while if the UK number is dialed the call should be answered by a specific sales team group).

In this situation, when defining a forwarding destination you should also activate the Keep Original CLD option available in advanced forwarding mode. This will instruct PortaSwitch that the call must be forwarded to destination 12061234567 (in this case, to a registered SIP phone with this number), while the To: in the INVITE message should contain the original DID. The PBX will then properly process incoming calls and will forward them to the correct recipient.

Ordinarily, when your phone rings, the only information available is the original caller’s phone number and, optionally, a caller name. While this works for simple residential calling, where it is always person A calling person B, in a PBX scenario there is usually more happening before your IP phone starts to ring. For instance, a secretary answers calls for several companies (Smart Software Design at 18005551234 and Synadyn Corporation at 12065559876), so she needs to greet callers differently depending on which company’s number they originally dialed. Similarly, when John is substituting for his colleague, he needs to answer calls to his phone from the sales queue differently from calls forwarded there from the technical support queue. So in a case where calls are being delivered to a phone via an entity such as a hunt group, external DID, or the like, it is obviously important to see not only the original caller’s identity (which in many cases is not even very useful) but also information about the entity which forwarded the call.

The visible call forward info feature in PortaSwitch allows users to easily determine the origin of an incoming call and react accordingly. So when account A (representing an external phone number, hunt group, etc.) in PortaSwitch is configured to forward calls to account B (representing the actual IP phone line), the forwarding is configured to replace “Display Name” information (the description displayed along with the caller’s phone number on the phone as it is ringing) with information identifying account A.

End users may set forwarding calls to a specific phone number directly on their IP phones, for example, via feature codes. An IP phone returns the “forward to” phone number in a 302 (“Moved Temporarily”) response to an incoming call request.

By default, forwarding calls to numbers set on IP phones is forbidden in PortaSwitch. If you want to allow call forwarding from a specific user’s IP phone, you need to configure a service policy for voice calls: Service policy > Attributes > SIP headers > select the Endpoint redirect action for untrusted network checkbox > select New call authorization in the dropdown list. Then, assign this service policy to the specific account directly or via the account’s product.

As a result, PortaSwitch will perform additional call authorization after receiving a 302 SIP redirect message. So, the call forwarding will be processed as if it was set via forwarding options in PortaSwitch (including authorization and charging the user who originated the forward for the forwarded part of the call). Call forwarding configured in PortaSwitch such as follow-me with multiple destination numbers, schedule, etc. is not used if the phone-initiated forwarding is enabled.

Note that by design, the 302 SIP redirect does not incorporate authentication, rendering it a potential security risk when used on the public Internet. This is why the ability to forward calls from an IP phone must be explicitly allowed for an account. Enable it only for accounts of customers who indeed require this feature and are aware of the implications.

It’s also possible to set specific IP addresses and domain names (trusted networks) to which PortaSwitch is allowed to redirect incoming calls without additional authorization. Refer to Delivering calls to customers with redirect servers chapter for more details.

Call forwarding from a SIP phone is available for members of a hunt group that has simultaneous ringing enabled.

For example, there are three IP phones that ring at the same time: phone A, phone B, and phone C. Staff member John, who usually answers phone C, wants to receive calls on his own mobile phone. So, John sets his mobile phone number as the “forward to” number directly on the phone C.

When a call comes to the hunt group, phone A, phone B, and John’s mobile phone ring simultaneously. PortaSwitch connects the call to the phone that is picked up first. The other phones stop ringing since PortaSIP sends a CANCEL request with a Reason header to the remaining SIP phones with the information that a call is answered:

Reason: SIP; cause=200; text="Call completed elsewhere"

Note that if the call was answered on phone A or B, other SIP phones from the hunt group don’t get a notification, while the mobile phone will still show “missed call” notification. And if the call is not answered on any IP phone including mobile or the call is sent straight to the voicemail, all IP phones will show the “missed call” notification.