Call forwarding

PortaSIP supports the following forwarding modes:

• Simple Forwarding – users can specify a single phone number to which the calls will be forwarded. Typically, with this mode, users manage call forwarding from their IP phones.
• Follow-me – users can specify multiple phone numbers for call forwarding. Also, for each phone number, it’s possible to define a time period when this number can be used, e.g., calls can be forwarded to the user’s mobile number from 8 AM to 9 PM, and to their colleague’s number – from 9 AM to 6 PM. Users can also specify whether these multiple numbers should be tried one after another, at the same time, in a random order, or calls should be distributed based on the set percentage. Typically, with the follow-me mode, users manage call forwarding from their self-care web interface.
• Forward to SIP URI – users can specify an IP address to which the calls will be forwarded. This is useful when calls should be forwarded directly to an external SIP switch.
• Advanced Forwarding – this mode is a combination of Follow-me and Forward to SIP URI modes, allowing users to specify multiple IP addresses and phone numbers for call forwarding.

To define the forwarding mode on the product level or for a specific account, open Product/Account > Services > Voice calls > Incoming calls > enable the Call forwarding feature > select the mode in the Call forwarding dropdown list.

Call forwarding can be configured based on the selected mode by the administrator or by the user on their account self-care interface.

With the follow-me mode, it’s possible to specify several alternative phone numbers to which calls can be sent if the dialed number is not available for any reason. Follow-me forwarding is activated when:

• The IP phone is offline (not registered).
• The line is busy because the user is on another call (the IP phone replies with the “486 Busy here” error code).
• No answer is received within a specific interval (e.g., 30 seconds) – it means either that the phone is unreachable due to a network error or the phone is online but nobody answers.

See the follow-me forwarding settings in the UI help.

How it works

Say user B configured the follow-me call forwarding the following way:

• if B does not pick up their IP phone within 30 seconds, the call is forwarded to their mobile phone number;
• if the call is still not answered within the next 15 seconds, it is forwarded to the phone number of the user’s colleague (user C);
• if C’s phone rings for 15 seconds and there’s no answer, the call is sent to voicemail.

Let’s see the call forwarding flow in details:

Step 1. User A dials the phone number of user B. PortaSIP receives an INVITE request.

Step 2. PortaSIP sends a request to PortaBilling for digest authorization.

Step 3. The call is authorized successfully. PortaBilling identifies that the account of user B has follow-me forwarding enabled, and sends the corresponding list of routes to PortaSIP for further call processing. The maximum call duration is calculated for each follow-me number, based on rates for the called account B and their available funds.

Step 4. PortaSIP sends the call to the IP phone of user B. User B doesn’t answer.

Step 5. Since the call is not connected within the defined 30 seconds timeout , PortaSIP sends the call to the next route – the mobile phone of user B.

Step 6. Since the call is not connected within the defined 15 seconds timeout , PortaSIP sends the call to the next route – the IP phone of user C. User C picks up the phone.

If user A sends the call to user B from an external network (off-net call), and such a call is answered by the IP phone of user C, then two xDRs will appear in PortaBilling:

• for the call A -> B (incoming call to B), and
• for the call A -> C (incoming call to C).

If A sends the call from your network (on-net call), the following xDRs will be created:

• for the call A -> B (outgoing call from A),
• for the call A -> C (incoming call to C).

The follow-me forwarding can be recursive (which means that a call is forwarded multiple times from one number to another).

Say, user A calls from their IP phone to user B and:

• User B forwards the call from their IP phone to the IP phone of user C;
• User C, in turn, forwards the call to the IP phone of user D;
• User D forwards calls to their mobile/landline phone number.

So, in the case of such a multi-hop follow-me (A->B->C->D->PSTN number), only two xDRs are produced (similar to a simple follow-me):

• An xDR for the caller (user A is charged for the outgoing call, A->B).
• A xDR for the forwarder outside the network, e.g., the last SIP account in the follow-me chain (user D is charged for the outgoing call to PSTN number).

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.