Call forking

This feature makes all SIP phones that are registered on a single account ring simultaneously. Consequently, if an end user has three SIP phones (e.g., a mobile application on a smartphone, on a tablet, and a desktop IP phone), he can receive calls to all three devices simultaneously. The same account ID and password can be applied for all end user endpoints.

To enable call forking on the Configuration server, go to ClusterSuite > PortaSIP Cluster > <your_sip-cluster>. Select MUB2bua group. Configure call forking options:

• call_forking – select how the SIP phones will ring:
  • one_by_one – SIP phones ring in priority sequence. The priority can be set in SIP phone settings (for SIP phones that support this feature).

    To set the priority, an end user needs to define the “q-value” parameter in the SIP phone settings. The SIP phone with the “q-value” 1 has the highest priority and is tried first among devices. And the SIP phone with the “q-value” 0 has the lowest priority, which means that this SIP phone is tried after all other devices with higher priority.

    If priority is not assigned to an IP phone, by default it has the lowest priority.

    For example, users can set the priority (q=0.7) in the settings of a Linphone device.

    If several SIP phones have the same priority, PortaSIP sends a call to the SIP phones in descending order beginning with the last registered SIP phone (the last registered SIP phone rings first).
  • grouped – SIP phones that take equal priority are grouped and ring simultaneously when called (from higher to lower priority).
  • parallel – all SIP phones ring simultaneously.
  • disabled – the last registered SIP phone rings.
    The time of registration is the time when the last REGISTER request was sent from the SIP phone.
• call_forking_seq_timeout – define the minimum time (in seconds) during which a SIP phone rings before a call is forwarded to the next SIP phone. This parameter is applied only for the one_by_one or grouped call forking options.

If your call forking mode is grouped or one-by-one, you can additionally fine-tune call forking per user so that PortaSIP stops sending a call to other devices when a user is either busy or declines the call.

To do this, configure the service policy, define the respective SIP response codes (486 and/or 603) for the stop_call_forking_code attribute and assign this service policy to the customer’s account.

When a customer rejects an incoming call, PortaSIP receives one of the defined response codes and stops forking the call to other devices.

Call forking enables an administrator to configure simultaneous calls to user SIP phones without creating individual accounts for each SIP phone. This reduces the administrative load and simplifies service management.

When call forking mode is grouped or parallel, SIP phones ring simultaneously. When a user picks up one of their phones, the other SIP phones stop ringing and do not show a “missed call” notification.

PortaSIP sends a CANCEL request with a Reason header to the remaining SIP phones. This request contains the information that a call is answered on another device:

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

Say John Doe has three SIP phones. All of them ring at once since parallel call forking mode is configured. When John picks up his phone, PortaSIP receives a 200 OK response code. PortaSIP includes this code in the Reason header in the CANCEL request and sends it to the remaining two phones. These phones handle the request and don’t show this incoming call as being missed.

Missed calls are not shown if a call is answered elsewhere if the following conditions are met:

• SIP devices support RFC 3326. See Supported SIP RFCs section for details.
• Call forking mode is grouped or parallel.
• A user picks up the phone (does not decline).
  If the call is not answered on any device or the call is sent straight to the voicemail, then all devices will show the “missed call” notification.