[Serusers] udp_send failed and can't get bye in accounting - sr-users

12 May 2005

When I try to route calls through my SER using sipp, I get there errors

May 11 17:17:34 proxy-ser ser[23159]: ERROR: udp_send:
sendto(sock,0x283555b8,650,0,0x28355960,16): Can't assign requested
address(49)
May 11 17:17:34 proxy-ser ser[23159]: msg_send: ERROR: udp_send failed
May 11 17:17:34 proxy-ser ser[23159]: ERROR: t_forward_nonack: sending
request failed

Google didn't turn up anything interesting on them. Anyone here know whats
up wiht them?

Also, I have accounting enabled to a database but I can not get it to log
Bye messages. I know they are going through my server from some debug
messages but they are not making it into the database. partial ser.cfg shown
below. Any other suggestions on it are also appriciated.

# Accounting
loadmodule "/usr/local/lib/ser/modules/acc.so"

# -- acc params --
# set the reporting log level
modparam("acc", "log_level", 1)
modparam("acc", "db_flag", 1)
#modparam("acc", "db_missed_flag", 1)
modparam("acc", "failed_transactions", 1)
modparam("acc", "report_ack", 0)
modparam("acc", "report_cancels", 1)
modparam("acc", "early_media", 1)

route{
#       xlog("L_ERR", "time [%Tf] method <%rm> r-uri <%ru> -
%tu\n");

        # initial sanity checks -- messages with
        # max_forwards==0, or excessively long requests
        if (!mf_process_maxfwd_header("10")) {
                sl_send_reply("483","Too Many Hops -- probebly a loop or
something");
                break;
        };
        if ( msg:len > max_len ) {
                sl_send_reply("513", "Message too big");
                break;
        };

        # we record-route all messages -- to make sure that
        # subsequent messages will go through our proxy; that's
        # particularly good if upstream and downstream entities
        # use different transport protocol
        record_route();

        /* grant Route routing if route headers present */
        # loose-route processing
#       if (loose_route()) {
#               t_relay();
#               break;
#       };

        # if the request is for other domain use UsrLoc
        # (in case, it does not work, use the following command
        # with proper names and addresses in it)
        if (uri==myself) {
            if(!(src_ip==x.x.x.x || src_ip==127.0.0.1)) {
                if (method=="REGISTER") {
                        if (!www_authorize("proxy-ser.voip.aebc.com",
"subscriber")) {
                                www_challenge("proxy-ser.voip.aebc.com",
"1");
                                break;
                        };

                        save("ser_location");
                        break;
                } else if (method=="INVITE"){
                        if (!proxy_authorize("proxy-ser.voip.aebc.com",
"subscriber")) {
                                proxy_challenge("proxy-ser.voip.aebc.com",
"1");
                                break;
                        };

                        if(!check_from()) {
                                sl_send_reply("403", "You can't lie
about
who you are");
                        }

                }
            }

                #Accounting if a call is started or ended
                if (method=="INVITE" || method=="BYE" ||
method=="CANCEL") {
#                        xlog("L_NOTICE", "Accounting
INVITE/BYE/CANCLE\n");
                        setflag(1);
                        acc_db_request("", "acc");
                }

                # native SIP destinations are handled using our USRLOC DB
                if (lookup("ser_location")) {
                    xlog("L_NOTICE", "Routing - Incommming call \n");
                    if (!t_relay()) {
                        sl_reply_error();
                    };
                    break;
                };

        } else {
            if(!(method=="ACK")) {
                sl_send_reply("403", "I only relay for my own
customers");
            }
        };

        # authorize only for INVITEs . RR/Contact may result in weird
        # things showing up in d-uri that would break our logic; our
        if (method=="INVITE") {
	##
	## Conditional relaying using if(uri=~ and rewritehostport omitted for
space and security
	##
        }

        # forward to current uri now; use stateful forwarding; that
        # works reliably even if we forward from TCP to UDP
        if (!t_relay()) {
                sl_reply_error();
        };