The full script used in this tutorial is available here.

The explanation for this is that in working modes "1" and "2", the mid-registrar may generate De-REGISTER requests in order to avoid stale registrations on the main registrar. The problem is that by default, it will not be able to authenticate itself to the main registrar since it is not provisioned with any credentials, so the mid-registrar IP address should simply be whitelisted on the main registrar in order for these de-registrations to properly go through.

The reason for this is that in working modes "1" and "2", the mid-registrar may generate De-REGISTER requests in order to avoid stale registrations on the main registrar. The problem is that by default, it will not be able to authenticate itself to the main registrar since it is not provisioned with any credentials, so the mid-registrar IP address should be white listed on the main registrar in order for de-registrations to work as well.

User authentication is a mandatory requirement for any real-world VoIP service, so we assume it is enabled for our platform as well. However, doing so will require additional configuration in order for the mid-registrar to properly work. We will have to whitelist the mid-registrar's IP address on the main registrar, thus skipping SIP authentication for all requests it may generate.

The reason for this is that in working modes "1" and "2", the mid-registrar may generate De-REGISTER requests in order to avoid stale registrations on the main registrar. The problem is that by default, it will not be able to authenticate itself to the main registrar since it does not know any credentials, so the mid-registrar IP address should be white listed on the main registrar in order for de-registrations to work as well.

In AOR throttling mode, the mid-registrar is aggregating both Alice's contacts (A and B) into a single contact (alice@mid-registrar) when forwarding registrations to the main registrar.

In AOR throttling mode, the mid-registrar is aggregating both Alice's contacts (A and B) into a single contact (alice@mid-registrar) when forwarding registrations to the main registrar.

The OpenSIPS mid-registrar is capable of throttling the amount of SIP registrations flowing through it, on the way to the main registrar. This is possible by configuring it to extend the SIP Contact expirations on the way out, and then accurately keeping track of both initial and extended values.

The module may also handle SIP call forking. Both serial/parallel forking can be achieved with the mid-registrar, potentially freeing up even more resources for the existing servers. This, in turn, will allow you to expand your user base with no additional software costs, minimal configuration of the current components and close to no additional hardware.

By making use of the powerful SIP user location implementation in

The module may also handle SIP call forking. Both serial/parallel forking can be achieved with the mid-registrar, thus potentially freeing up even more resources for the existing servers. This, in turn, will allow you to expand your user base with no additional software costs, minimal configuration of the current components and close to no additional hardware.

Call flow (throttling registrations by Contact)

The mid-registrar can additionally take over all call forking responsibilities. In order to enable this, we only need to switch it to "mode = 2" (AOR throttling).

Call flow (throttling registrations by AOR)

http://opensips.org/pub/images/mid-registrar-aor-throttling.png

Notice how the mid-registrar is aggregating both Alice's contacts (A and B) into a single contact (alice@mid-registrar) when forwarding registrations to the main registrar.

This call flow shows how the mid-registrar's "AOR throttling" mode allows it to take over all call forking responsibilities, freeing up even more resources for the main registrar.

This call flow shows how the mid-registrar's "AOR throttling" mode allows it to take over all parallel forking responsibilities, freeing up even more resources for the main registrar.

This call flow shows how the mid-registrar's "AOR throttling" mode allows it to take over all call forking responsibilities, freeing up even more resources for the main registrar.

Although the rest of the script stays the same, the mid_registrar_save() and mid_registrar_lookup() functions will behave differently. For example, when saving contacts, all Contact header fields of REGISTER requests will be aggregated into a single one. When looking up contacts, the entire branch set will be populated (see $branch), thus preparing to fork calls in parallel.

• "mode" - the working mode of the module. In this case, "2" means "AOR throttling", where the module will both reduce the amount of registration traffic sent to the main registrar and also aggregate contacts into a single one when forwarding registrations to it. The latter will allow it to do parallel forking.

The mid-registrar can additionally take over all call forking responsibilities. We only need to switch it to "mode = 2" (AOR throttling).

Notice how each of Alice's devices first registers with both registrars, after which subsequent registrations are absorbed at mid-registrar level.

First, we will configure the mid-registrar to greatly increase the outgoing Contact expiration values. After doing so, it will internally keep track of the initial expirations as well as the extended ones, in order to decide if a REGISTER should be forwarded to the main registrar or not.

First, we will configure the mid-registrar to greatly increase the outgoing Contact expiration values. After doing so, it will internally keep track of the extended expirations as well, in order to decide if a REGISTER should be forwarded to the main registrar or not.

In the following, we will extend the default OpenSIPS script with mid-registrar capabilities in two steps. By doing this, we will actually go through two working modes of the module: contact throttling and AOR throttling.

http://opensips.org/pub/images/mid-registrar-contact-throttling.png

Call flow (parallel forking)

Although the rest of the script stays the same, the mid_registrar_save() and mid_registrar_lookup() will behave differently. For example, when saving contacts, all Contact header fields of REGISTER requests will be aggregated into a single one. When looking up contacts, the entire branch set will be populated (see $branch), thus preparing to fork calls in parallel.

• "mode" - the working mode of the module. In this case, "2" means "AOR throttling", where the module will both reduce the amount of registration traffic sent to the main registrar and also aggregate contacts into a single one when forwarding registrations to it. The latter feature will allow it to do parallel forking.

Contact lookup is almost identical to the stock OpenSIPS script. The only big difference is that we are using mid_registrar_lookup() instead of lookup(). Note that mid_registrar_lookup() will behave according to the insertion and working modes. In our case, it will only populate the Request-URI variable (see $ru) since the module is in working "mode = 1".

Contact lookup is almost identical to the stock OpenSIPS script. The only big difference is that we are using mid_registrar_lookup() instead of lookup(). Note that mid_registrar_lookup() will behave according to the insertion and working modes. In our case, it will only populate the Request-URI variable (see $ru) since it is configured with "mode = 1".

modparam("mid_registrar", "mode", 1) /* 0 = mirror / 1 = ct / 2 = AoR */

modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */

Throttling registrations

modparam("mid_registrar", "mode", 1) /* 0 = mirror / 1 = ct / 2 = AoR */

• "mode" - the working mode of the module. In this case, "1" means "Contact throttling", where the module will reduce the amount of registration traffic sent to the main registrar

REGISTER handling

For all registrations, we make sure to call mid_registrar_save(). As stated in its documentation, it will not process the contacts immediately, but rather do the necessary changes to the REGISTER request before it is relayed to the main registrar, while also preparing to transparently handle its replies. The above code stays the same regardless of the module's working mode or insertion mode. We are now done with REGISTER request handling!

INVITE handling

Contact lookup is almost identical to the stock OpenSIPS script. The only big difference is that we are using mid_registrar_lookup() instead of lookup(). Note that mid_registrar_lookup() will behave according to the insertion and working modes. In our case, it will only populate one branch for each call, since it is configured with "mode = 2".

Call flow (throttled registrations)

The diagram below shows two devices of the same user (A and B) periodically registering to the platform. In "Contact throttling" mode, the main registrar will be notified about the presence of each SIP contact on the mid-registrar. When receiving a call, the mid-registrar will simply relay it to the user.

Parallel forking support

Module configuration

loadmodule "mid_registrar.so"
modparam("mid_registrar", "mode", '''2''') /* 0 = mirror / 1 = ct / 2 = AoR */
modparam("mid_registrar", "outgoing_expires", 7200)
modparam("mid_registrar", "insertion_mode", 0) /* 0 = contact; 1 = path */

Additional explanations:

• "mode" - the working mode of the module. In this case, "2" means "AOR throttling", where the module will both reduce the amount of registration traffic sent to the main registrar and also aggregate contacts into a single one when forwarding registrations to it. The latter will allow it to do parallel forking.

Although the rest of the script stays the same, the mid_registrar_save() and mid_registrar_lookup() will behave differently. For example, when saving the contacts, all Contact header fields of REGISTER requests will be aggregated into a single one. When looking up contacts, the entire branch set will be populated (see $branch), thus preparing to fork calls in parallel.

Call flow (call forking)

This call flow shows how the mid-registrar "AOR throttling" mode also causes it to take over all call forking responsibilities, freeing up even more resources for the main registrar.

This tutorial will teach you how to configure an OpenSIPS mid-registrar in front of an existing SIP PBX or registrar. We will configure this new component to take over most of the SIP registrations and all call forking for the existing server. This will allow you to leverage existing infrastructure in order to continue to grow (as subscribers and as registration traffic) while keeping the current low-resources registrar server.

In the following, we will extend the default OpenSIPS script with mid-registrar capabilities in two steps. This will actually showcase two working modes of the module, namely: contact throttling and AOR throttling.

Contact throttling

First, we will configure the mid-registrar to reduce the outgoing Contact expiration values. After doing so, it will internally keep track of the extended expirations as well, in order to decide if a REGISTER should be forwarded to the main registrar or not.

Module configuration

This tutorial will teach you how to configure an OpenSIPS mid-registrar in front of an existing SIP PBX or registrar. We will configure this new component to take over most of the SIP registrations and all call forking for the existing server. This will allow you to leverage existing infrastructure in order to continue to grow (as subscribers and as registration traffic) while keeping the existing low-resources registrar server.

How does the mid-registrar work?

The OpenSIPS mid-registrar is capable of throttling the amount of SIP registrations flowing through it, on the way to the main registrar. This is possible by extending the SIP Contact expirations on the way out, and then accurately keeping track of both initial and extended values.

Call forking is another feature closely related to the OpenSIPS registrars. Both serial/parallel forking can be achieved with the mid-registrar as well, thus potentially freeing up even more resources for the existing servers. This, in turn, will allow you to expand your user base with no additional software costs, minimal configuration of the current components and close to no additional hardware.

Scenario

• "mode" - the working mode of the module. In this case, "2" means "AOR throttling", where the module will both reduce the amount of registration traffic sent to the main registrar, and also aggregate contacts into a single one when forwarding registrations to it.

We first load the mid_registrar module and set its parameters. Going through each parameter:

The reason for this is that in working modes "1" and "2", the mid-registrar may generate De-REGISTER requests in order to avoid stale registrations on the main registrar. The problem is that it will not be able to authenticate itself to the main registrar since it does not know any credentials, so the mid-registrar IP address should be white listed on the main registrar in order for de-registrations to work as well.

User authentication is a mandatory requirement for any real-world VoIP service, so we assume it is enabled for our platform as well. This will require us to white list the mid-registrar IP on the main registrar, and skip authentication for all requests generated by it.

The reason for this is that in working modes "1" and "2" the mid-registrar may generate De-REGISTER requests in order to avoid stale registrations on the main registrar). The problem is that it will not be able to authenticate itself to the main registrar since it does not know any credentials, so the mid-registrar IP address should be white listed on the main registrar in order for de-registrations to work as well.

• "mode" - the working mode of the mid_registrar module. In this case, "2" means "AOR throttling", where the module will both reduce the amount of registration traffic sent to the main registrar, and also aggregate contacts into a single one when forwarding registrations to it.
• "outgoing_expires" - the default value for the expirations of the contacts that the mid-registrar relays to the main registrar. The mid_registrar_save() function also has a similar optional parameter, for more fine grained control.

By adding this inexpensive mid-registrar traffic conversion front-end for our servers, we will reduce their incoming rate of registrations. This, in turn, will free up a lot of platform resources, allowing it to redirect its resources to handling more subscribers. The resulting architecture will resemble the following:

By adding this mid-registrar traffic conversion front-end for our servers, we will reduce their incoming rate of registrations. This, in turn, will free up a lot of platform resources, allowing it to redirect its resources to handling more subscribers. The resulting architecture will resemble the following:

This call flow shows how the mid-registrar "AOR throttling" mode also causes it to take over all call forking responsibilities, freeing up even more resources for the main registrar.

\\

The diagram below shows two devices of the same user (A and B) periodically registering to the platform. In "AOR throttling" mode, the main registrar will only be notified about the presence of the AOR on the mid-registrar, rather than each of its devices. When receiving calls for this AOR, the mid-registrar will ensure they are delivered to each user device, in parallel.

The diagram below shows two devices of the same user (A and B) registering to the platform. In "AOR throttling" mode, the main registrar will only be notified about the presence of the AOR on the mid-registrar, rather than each of its devices. When receiving calls for this AOR, the mid-registrar will ensure they are delivered to each user device, in parallel.

\\

SIP Call flows

After several phases of testing, we later find out that registration processing is rather expensive on the current system, which immediately turns it into a bottleneck. A cheap solution to this problem is to integrate an OpenSIPS mid-registrar into our platform, since it is capable of converting incoming high-rate registration traffic (mobile users to mid-registrar) into a low-rate variant (mid-registrar to main registrar). Its main jobs will include soaking up most of this registration traffic, as well as handling parallel forking.

Our task is to find a solution to scale the platform to 500,000 subscribers. We first do an assessment of the types of VoIP traffic being handled by the platform, only to reach an interesting conclusion: 80%+ of the traffic that is hitting our servers is made up of REGISTER requests! Is this correct? Well, it might be, as mobile devices have short registration lifetimes (60 seconds). With this conclusion, we have spotted a potential bottleneck: registration traffic handling!

This is our initial example VoIP platform. Its services are provided by a layer of multi-purpose servers (represented as the main registrar box). To name a few services of this current platform: conferencing, call pickup and internet messaging (IM). Currently, the platform servers seem to reach peak usage when handling around 50,000 mobile device subscribers.

This is our initial example VoIP platform. Its services are provided by a layer of multi-purpose servers (represented as the main registrar box). To name a few services of this current platform: conferencing, call pickup and internet messaging (IM). Currently, the platform servers are reaching peak usage around 50,000 mobile device subscribers.

This tutorial will teach you how to deploy an OpenSIPS mid-registrar to an existing platform (e.g. a hosted PBX) in order to throttle the amount of registrations flowing into its existing servers. This will allow you to expand your user base and grow your business with no additional software costs, minimal configuration of the current components and close to no additional hardware.

After several phases of testing, we later find out that registration processing is rather expensive on the current system, which turns registration traffic processing into a bottleneck. A cheap solution to this problem is to integrate an OpenSIPS mid-registrar into our platform, since it is capable of converting incoming high-rate registration traffic (mobile users to mid-registrar) into a low-rate variant (mid-registrar to main registrar). Its main jobs will include soaking up most of this registration traffic, as well as handling parallel forking.

After several phases of testing, we later find out that registration processing is rather expensive on the current system, which turns registration traffic processing into a bottleneck. A cheap solution to this problem is to integrate an OpenSIPS mid-registrar into our platform, capable of converting incoming high-rate registration traffic (mobile users to mid-registrar) into a low-rate variant (mid-registrar to main registrar). Its main jobs will include soaking up most of this registration traffic, as well as handling parallel forking.

By adding this mid-registrar traffic conversion front-end for our servers, we will reduce the rate of outgoing registrations. This, in turn, will free up a lot of platform resources, allowing it to redirect its resources to handling more subscribers. The resulting architecture will resemble the following:

By adding this mid-registrar front-end, which is capable of dramatically lowering incoming registration traffic for these servers, we will reduce the rate of outgoing registrations (mid-registrar to main registrar). This, in turn, will free up a lot of platform resources, allowing it to redirect its resources to handling more subscribers. The resulting architecture will resemble the following:

Our task is to find a solution to scale the platform to 500,000 subscribers. We first do an assessment of the types of VoIP traffic being handled by the platform, only to reach an interesting conclusion: 70%+ of the traffic that is hitting our servers is made up of REGISTER requests! Is this correct? Well, it might be, as mobile devices have short registration lifetimes (60 seconds). With this conclusion, we have spotted a potential bottleneck: registration traffic handling!

After several phases of testing, we later find out that registration processing is rather expensive on the current system, which turns registration traffic processing into a bottleneck. So we proceed with implementing a front-end OpenSIPS registrar, dedicated to soaking up most of this registration traffic, as well as handling parallel forking.

Our task is to find a solution to scale the platform to 500,000 subscribers. We first do an assessment of the types of VoIP traffic being handled by the platform, only to reach an interesting conclusion: 70%+ of the traffic that is hitting our servers is made up of REGISTER requests! Is this correct? Well, it might be, as mobile devices have short registration lifetimes (60 seconds). With this conclusion, we have spotted a potential bottleneck: registration traffic handling! Several phases of testing later reveal that registration processing is rather expensive on the current system. So we proceed with implementing a front-end OpenSIPS registrar, dedicated to soaking up most of the registration traffic, as well as handling parallel forking.

By adding a mid-registrar traffic conversion front-end for these servers, we will reduce the rate of outgoing registrations (mid-registrar to main registrar). This, in turn, will free up a lot of platform resources, allowing it to redirect its resources to handling more subscribers. The resulting architecture will resemble the following:

Our task is to find a solution to scale the platform to 500,000 subscribers. We first do an assessment of the types of VoIP traffic being handled by the platform, only to reach an interesting conclusion: 70%+ of the traffic that is hitting our servers is made up of REGISTER requests! Is this correct? Well, it might be, as mobile devices have short registration lifetimes (60 seconds). With this conclusion, we have spotted the bottleneck: registration traffic handling! So we proceed with implementing a front-end registrar, capable of soaking up this specific type of traffic.

By adding a mid-registrar traffic conversion front-end for these servers, we will free up a lot of platform resources, allowing it to redirect its resources to handling more subscribers. The resulting architecture will resemble the following:

Our task is to find a solution to scale the platform to 500,000 subscribers. We first do an assessment of the types of VoIP traffic being handled by the platform, only to reach an interesting conclusion: 70%+ of the traffic that is hitting our servers is made up of REGISTER requests! Is this correct? Well, it might be, as mobile devices have short registration lifetimes (60 seconds). So we proceed with implementing a front-end registrar, capable of soaking up all the registration traffic.

Our task is to find a solution to scale the platform to 500,000 subscribers. We first do an assessment of the types of VoIP traffic being handled by the platform, only to reach an interesting conclusion: 70%+ of the traffic that is hitting our servers is made up of REGISTER requests! This may actually be true, as mobile devices have short registration lifetimes (60 seconds). So we proceed with implementing a front-end registrar, capable of soaking up all the registration traffic.

This tutorial will teach you how to deploy an OpenSIPS mid-registrar to an existing platform (e.g. a hosted PBX) in order to reduce the rate of registrations to its existing servers. This will allow you to expand your user base and grow your business with no additional software costs, minimal configuration of the current components and close to no additional hardware.

This is our initial example VoIP platform. Its services are provided by a layer of multi-purpose servers (represented as the main registrar box). To name a few services of the current platform: conferencing, call pickup and internet messaging (IM). Currently, the platform servers are reaching peak usage around 50,000 mobile device subscribers.

Our task is to find a solution to scale the platform to 500,000 subscribers. We first do an assessment of the types of VoIP traffic being handled by the platform, only to reach an interesting conclusion: 70%+ of the traffic that is hitting our servers is made up of REGISTER requests! This is entirely possible, as mobile devices have short registration lifetimes (60 seconds). So we proceed with implementing a front-end registrar, capable of soaking up all the registration traffic.

By adding a mid-registrar traffic conversion front-end for these servers, we will free up a lot of platform resources, allowing us to support more subscribers. The resulting architecture will resemble the following:

This is our initial example platform. Its voice services are provided by a layer of multi-purpose servers (main registrar layer). These servers also include SIP registration handling. By adding a mid-registrar traffic conversion front-end for these servers, we will free up a lot of platform resources, allowing us to support more subscribers. The resulting architecture will resemble the following:

http://www.opensips.org/pub/images/mid-registrar-platform-before.png

http://opensips.org/pub/images/mid-registrar-platform-after.png

Call flows

Registration (AOR throttling)

http://opensips.org/pub/images/mid-registrar-aor-throttling.png

Calling (parallel forking)

http://opensips.org/pub/images/mid-registrar-parallel-forking.png

Module configuration

REGISTER handling

INVITE handling

Assuming the existing platform is using SIP authentication (if not, then please enable it!!), note that in working modes "1" and "2", the mid-registrar may generate De-REGISTER requests, in order to avoid stale registrations on the main registrar. Since by default, OpenSIPS will not be able to authenticate itself to the main registrar (it has no credentials!), the mid-registrar IP address should be white listed on the main registrar.

\\

Contact lookup is almost identical to the stock OpenSIPS script. The only big difference is that we are using mid_registrar_lookup() instead of lookup(). Note that mid_registrar_lookup() will behave according to the insertion and working modes. In our case, it may populate more than one branch for this call, since "mode = 2" instructs the mid-registrar to also take over parallel forking.

The full script used in this tutorial is available here.

The full script is available here.

Assuming the existing platform is using SIP authentication (if not, then please enable it!!), note that in working modes "1" and "2", the mid-registrar may generate De-REGISTER requests, in order to avoid zombie registrations. Since by default, OpenSIPS will not be able to authenticate itself to the main registrar (it has no credentials!), the mid-registrar IP address should be white listed on the main registrar.

The full script is available for download here.

modparam("mid_registrar", "insertion_mode", 0) /* 0 = contact; 1 = path */

For all registrations, we make sure to call mid_registrar_save(). As stated in its documentation, it will not process the contacts immediately, but rather do the necessary changes to the REGISTER request before it is relayed to the main registrar, while also preparing to transparently handle its replies. The above code stays the same regardless of the module's working mode or insertion mode. We are now done with REGISTER request handling!

Contact lookup is identical to the stock OpenSIPS script. Note that mid_registrar_lookup() will behave according to the insertion and working modes. In our case, it may populate more than one branch for this call, since "mode = 2" instructs the mid-registrar to also take over parallel forking.

SIP Authentication

Note that in working modes "1" and "2", the mid-registrar may generate De-REGISTER requests, in order to avoid zombie registrations. Since by default, OpenSIPS will not be able to authenticate itself to the main registrar (it has no credentials!), the mid-registrar IP address should be white listed on the main registrar.

Downloads

The full script is available .

    # initial requests from main registrar, need to look them up!

Example

    # initial requests from main registrar --> need to look them up!
    if (is_method("INVITE|MESSAGE") && $si == "10.0.0.3" && $sp == 5070) {
        # do lookup with method filtering
        xlog("looking up $ru!\n");
        if (!mid_registrar_lookup("location")) {
            t_reply("404", "Not Found");
            exit;

        t_relay();

Example

Next, we proceed with contact lookup during calls or instant messages:

Example

For all registrations, we make sure to call mid_registrar_save(). As stated in its documentation, it will not process the contacts immediately, but rather do the necessary changes to the REGISTER request before it is relayed to the main registrar, while also preparing to transparently handle its replies. We are now done with REGISTER request handling!

Example

For all registrations, we make sure to call mid_registrar_save(). As stated in its documentation, it will not process the contacts immediately, but rather do the necessary changes to the REGISTER request before it is relayed to the main registrar, while also preparing to transparently handle its replies. We are done with REGISTER request handling, the replies will be properly taken care of by the mid-registrar!

Example

Example

For all registrations, we make sure to call mid_registrar_save(). As stated in its documentation, it will not process the contacts immediately, but rather do the necessary changes to the REGISTER request, and prepare to transparently handle its replies. We are done with REGISTER request handling, the replies will be properly taken care of by the mid-registrar!

We now proceed with contact lookup handling:

    if (is_method("REGISTER")) {
        mid_registrar_save("location");
        switch ($retcode) {
        case 1:
            xlog("forwarding REGISTER to main registrar ($$ci=$ci)\n");
            $ru = "sip:10.0.0.3:5070";
            t_relay();
            break;
        case 2:
            xlog("absorbing REGISTER! ($$ci=$ci)\n");
            break;
        default:
            xlog("failed to save registration! ($$ci=$ci)\n");
        }

        exit;
    }

Example

    if (is_method("REGISTER")) {

            xlog("forwarding REGISTER to main registrar ($$ci=$ci)\n");

            t_relay();

            xlog("absorbing REGISTER! ($$ci=$ci)\n");

            xlog("failed to save registration! ($$ci=$ci)\n");

Example

    if (is_method("REGISTER"))
    {
        mid_registrar_save("location");
        switch ($retcode) {
        case 1:
            # hashing algorithm, etc. Destination registrar is selected!
            $ru = "sip:10.0.0.3:5070";
            #$rd = "10.0.0.3";
            #$rU = "liviu";
            #$rp = 5070;

            #uac_replace_to("Liviu Chircu", "sip:liviu@8.8.8.8");

            if (!t_relay())
                send_reply("500", "Internal Error 77");
            xlog("NEED TO FORWARD!!! '$rm' with $(hdr(Expires))\n");
            break;
        case 2:
            xlog("---- NO NEED TO FORWARD!!!\n");
            break;
        default:
            xlog("ERRRRRRRORRRRRRRRRR!!!\n");
        }

        exit;
    }

Example

Let's extend the default OpenSIPS script with mid-registrar capabilities, step by step:

Example

• "insertion_mode" - specifies how the mid-registrar will insert itself on the call flow. Insertion mode "0" leads to rewrite of the Contact header field "host" part, while in insertion mode "1", the mid-registrar will append a Path header field to all REGISTER requests. In both cases, the header field values will contain the network interface used to relay the request.

Example

• "insertion_mode" - specifies how the mid-registrar will insert itself on the call flow. Insertion mode "0" leads to rewrite of the Contact header field "host" part, while in insertion mode "1", the mid-registrar will append a Path header field to all REGISTER requests.

Example

modparam("mid_registrar", "outgoing_expires", 7200)

Example

Example

loadmodule "mid_registrar.so" modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ modparam("mid_registrar", "outgoing_expires", 100) modparam("mid_registrar", "contact_routing_mode", 0) /* 0 = contact; 1 = path */

modparam("mid_registrar", "contact_match_mode", 0) /* 0 = by param; 1 = by user */ modparam("mid_registrar", "contact_match_param", "ionel")

Example

• "mode" - the working mode of the mid_registrar module. In this case, "2" means "AOR throttling", where the module will both reduce the amount of registration traffic to the main registrar, and also aggregate contacts into a single one when forwarding registrations to it.
• "outgoing_expires" - the default value for the expirations of the contacts that the mid-registrar will relay to the main registrar. The mid_registrar_save() function also has a similar optional parameter, for more fine grained control.
• "insertion_mode" - specifies how the mid-registrar will insert itself on the call flow. Insertion mode "0" leads to rewrite of the Contact header field "host" part, while in insertion mode "1", the mid-registrar will simply use a Path header field.

Example

Example

• a
• b
• c

Example

Example

Example scenario

OpenSIPS script

http://www.opensips.org/images/tc-setup.png

We first load the module and set its parameters. Going through each parameter:

Example

This is our initial example platform. Its voice services are provided by a layer of multi-purpose servers. These servers also include SIP registration handling. By adding a mid-registrar traffic conversion front-end for these servers, we will free up a lot of platform resources, allowing us to support more subscribers. The resulting architecture will resemble the following:

\\

Example platform

http://www.opensips.org/images/tc-setup.png

This is our initial example platform. Its voice services are built on top of an all-in-one box, which includes SIP registration handling.

http://www.opensips.org/images/tc-setup.png

This tutorial will teach you how to deploy an OpenSIPS mid-registrar to an existing platform (e.g. a hosted PBX) in order to reduce the rate of incoming registrations into the existing servers. This will allow you to expand your user base and grow your business with no additional software costs, minimal configuration of the current components and close to no additional hardware.

Documentation -> Tutorials -> Scaling registrations with an OpenSIPS mid-registrar

This page has been visited 21566 times.

Scaling registrations with an OpenSIPS mid-registrar

written by Liviu Chircu

(:toc-float Table of Content:)

Tutorial Overview

This tutorial will teach you how to deploy an OpenSIPS mid-registrar to an existing platform (i.e. a hosted PBX) in order to reduce the rate of incoming registrations into the existing servers. All this can be done with minimal configuration and almost no additional hardware.

Initial platform

Final platform

This tutorial illustrates the required steps in order to perform audio transcoding with the D-series cards manufactured by Sangoma, using the sngtc_server daemon and the OpenSIPS sngtc module as its client. The latest version of the transcoding library, as of 1 August 2013 is: sng-tc-linux-1.3.4.1

\\