[OpenSER-Users] Openser not processing requests at rate being sent to it

Brian Peters brian at proximosystems.com
Fri May 23 22:32:26 CEST 2008


Mik,

Response to your questions below:

-----Original Message-----
From: Mik Cheez [mailto:michael_bulk at wildgate.com] 
Sent: Friday, May 23, 2008 3:34 PM
To: Brian Peters
Cc: users at lists.openser.org
Subject: Re: [OpenSER-Users] Openser not processing requests at rate being
sent to it

Brian Peters wrote:
> I am doing what I thought was a simple volume test that OpenSER should 
> be able to handle, but the results I am getting so far show it is not 
> handling the load I'm sending it.
> 
>  
> 
> Here is my configuration:
> 
>  
> 
>  
> 
> -          OpenSER 1.3.1
> 
> -          Simple script that uses OpenSER as a proxy to forward 
> requests to a carrier. All it does is rewrite the host and port of the 
> R-URI and relays to the carrier.
> 
> -          children=16
> 
> -          shared memory set to 1 G. (-m 1000)
> 
> -          using transaction module to handle the requests.
> 
> -          Sending 10 INVITE requests per second to OpenSER using
Asterisk.
> 
>  
> 
> When I do a "tcpdump" trace of the network traffic to/from OpenSER,  it 
> is clear that a large percentage of the INVITE requests sent to OpenSER 
> were not handled. Asterisk needed to resend the INVITE requests several 
> times before OpenSER would handle them, and in about 20% of the cases 
> Asterisk terminated the INVITES because it reached the timeout of 30 
> seconds without any response.
> 
>  
> 
> If I go directly from asterisk to the carrier, this test works without 
> any issues. I'm not sure what the limitations are of OpenSER, but this 
> seems like something it should be able to handle.
> 
>  
> 
> Any help or information on how to configure OpenSER so it will work 
> would be appreciated.
> 
>  
> 
> Thanks,
> 
>  
> 
> Brian.
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Users mailing list
> Users at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users

You have a config file to share?
Are your network settings correct?
Are you doing the dump on the OpenSER box, or the Asterisk?
How are your system resources on the box (e.g. running 'top')?

10 invites per second is really nothing for OpenSER, so something else 
must be going on.

---

1. the network settings on the servers are OK. We have used the servers in
production environment without OpenSER (asterisk direct to carrier) and at
much higher volume than we are testing.

2. The tcpdump is being done from the OpenSER box so that I could see what
OpenSER was receiving and sending. The server is clearly receiving the
INVITE requests, and OpenSER is not responding.

3. System resources are not an issue. The server is only being used for
OpenSER, and CPU usage is barely reaching 1%. Network is only being used for
OpenSER.

4. for the config file, here it is (with the IP/hosts blanked out):


## begin openser script ##

#
# $Id: openser.cfg 3542 2008-01-16 15:00:34Z miconda $
#
# OpenSER basic configuration script
#     by Anca Vamanu <anca at voice-system.ro>
#
# Please refer to the Core CookBook at
http://www.openser.org/dokuwiki/doku.php
# for a explanation of possible statements, functions and parameters.
#


####### Global Parameters #########

debug=3
fork=yes
log_stderror=no

listen=udp:xxx.xxx.xxx.xxx:5060
port=5060
# disable_tcp=yes

alias=foo.com

sip_warning=0

check_via=no
dns=off
rev_dns=off
children=8
log_name="openser-test.log"
log_facility=LOG_LOCAL0

disable_dns_blacklist=yes
disable_dns_failover=yes

####### Modules Section ########

#set module path
mpath="/usr/local/openser-1.3.1//lib/openser/modules/"

loadmodule "textops.so"
loadmodule "sl.so"
loadmodule "maxfwd.so"
loadmodule "uri.so"
loadmodule "xlog.so"

# ----- mi_fifo -----
loadmodule "mi_fifo.so"
modparam("mi_fifo", "fifo_name", "/tmp/openser_1.3.1_fifo")

# ----- rr -----
loadmodule "rr.so"
modparam("rr", "append_fromtag", 0)
modparam("rr", "enable_full_lr", 1)

# ----- tm -----
loadmodule "tm.so"
modparam("tm", "fr_timer", 40)
modparam("tm", "fr_inv_timer", 60)
modparam("tm", "wt_timer", 20)
modparam("tm", "noisy_ctimer", 1)

route{
        xlog("New request - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");

        if (!mf_process_maxfwd_header("10")) {
                sl_send_reply("483","Too Many Hops");
                exit;
        }

        if (has_totag()) {
                # sequential request withing a dialog should
                # take the path determined by record-routing
                if (loose_route()) {
                        route(1);
                } else {
                        if ( is_method("ACK") ) {
                                if ( t_check_trans() ) {
                                        route(1);
                                        exit;
                                } else {
                                        exit;
                                }
                        }
                        sl_send_reply("403","No proper route");
                }
                exit;
        }

        #initial requests

        # CANCEL processing
        if (is_method("CANCEL"))
        {
                if (t_check_trans())
                        route(1);
                exit;
        }

        t_check_trans();

        if (!is_method("INVITE"))
        {
                sl_send_reply("403","Not routable");
                exit;
        }

        record_route();

        # route invites to carrier
        route(2);
}


route[1] {
        if (!t_relay()) {
                sl_reply_error();
        };
        exit;
}

route[2] {
        rewritehostport("yyy.yyy.yyy.yyy:5060");

        xlog("routing INVITE request to carrier $ou -> $ru\n");

        t_on_failure("1");
        route(1);
}


failure_route[1] {
        if (t_was_cancelled() ||  t_check_status("486|487")) {
                exit;
        }

        xlog("Routing to carrier failed: $fu => $ru ($(T_reply_code))\n");
}

## end openser script ##


Thanks,

Brian.






More information about the sr-users mailing list