Paid Consultation Request

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Geoffrey Mina
Thanks for your clarification.  I do see where you are coming from.

Here is my config with some better comments. I have also attached the
file in case the email client mangles the formatting.

thanks,
Geoff

#
# OpenSIPS configuration
#     by Geoff Mina
#
# Please refer to reference http://www.opensips.org/dokuwiki/doku.php
# for a full description of all modules and functions
#
#


###### Global Parameters #####
debug=1
log_stderror=no
log_facility=LOG_LOCAL0
fork=yes
children=16
disable_tcp=yes
listen=eth0:5060
listen=eth1:5060
port=5060
server_header="Server: G-Tel SIP Gateway"

#fork=no
#log_stderror=yes

##### Module Loading and Param Setting #####
mpath="/usr/local/lib64/opensips/modules/"
loadmodule "sl.so"
loadmodule "db_mysql.so"
loadmodule "maxfwd.so"
loadmodule "uri.so"
loadmodule "textops.so"

## Enable FIFO ##
loadmodule "mi_fifo.so"
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")

## Enable TM ##
loadmodule "tm.so"
modparam("tm","fr_timer",10)
modparam("tm","fr_inv_timer",30)

## Enable RR ##
loadmodule "rr.so"
modparam("rr", "enable_full_lr",0)
modparam("rr", "append_fromtag",1)
modparam("rr", "enable_double_rr",1)
modparam("rr", "add_username",0)

## Enable Logging ##
loadmodule "xlog.so"
modparam("xlog", "buf_size",4096)
modparam("xlog", "force_color",0)

## Enable SipTrace module for debugging SIP transactions ##
loadmodule "siptrace.so"
modparam("siptrace","db_url","mysql://[removed]:[removed]@localhost/opensips")
modparam("siptrace","table","sip_trace")
modparam("siptrace","trace_on",0)
modparam("siptrace","trace_flag",13)

## Enable Dispatcher module ##
loadmodule "dispatcher.so"
modparam("dispatcher","flags",2)
modparam("dispatcher","dst_avp","$avp(i:271)")
modparam("dispatcher","grp_avp","$avp(i:272)")
modparam("dispatcher","cnt_avp","$avp(i:273)")
modparam("dispatcher","ds_ping_method","OPTIONS")
modparam("dispatcher","ds_ping_from","sip:monitoring@[removed].com")
modparam("dispatcher","ds_ping_interval",30)
modparam("dispatcher","ds_probing_mode",1)
modparam("dispatcher", "ds_probing_threshhold", 2)

###########################################################################
## Request route 'main'
###########################################################################
route{
       
        ##
        ## Start with some simple logging and sip tracing
        ## For the time being we are going to sip trace everything
        ## just to make sure all packets are flowing properly
        ##
        xlog("L_INFO", "New request - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
        setflag(13);
        sip_trace();
       
       
        ##
        ## Initial sanity check to ensure the message isn't too big
        ##
        if(msg:len > max_len){
                xlog("L_INFO", "Message too big\n");
                t_reply("513", "Message Too Big");
                exit;
        }

        ##
        ## Ensure we aren't in a tight loop for some reason
        ## this number could probably be lower.
        ##
        if (!mf_process_maxfwd_header("70")){
                xlog("L_INFO", "Too many hops\n");
                t_reply("483", "Too Many Hops");
                exit;
        }

        ##
        ## If this is anything other than a REGISTER method
        ## we want to insert the Record-Route header so the
        ## return path flows back through the gateway system
        ##
        if(!is_method("REGISTER")){
                xlog("L_INFO", "Recording Route info\n");
                record_route();
        }

       
        if(is_method("INVITE")){
                ##
                ## If the method is an INVITE we are going to enter the
                ## route[1] method which is responsible for invoking the
                ## dispatcher and relaying the request to the end point
                ##
                xlog("L_INFO", "Method is an INVITE, fetching next from dispatcher\n");
                route(1);
        }else if(is_method("OPTIONS")){
                ##
                ## If the method is an OPTIONS we are simply going to respond
                ## with a 200 OK.  The internal monitoring platform (nagios) will be
                ## monitoring the health of the gateway via the check_sip plugin
                ##
                xlog("L_INFO", "Method is an OPTIONS, probably just monitoring\n");
                sl_send_reply("200","OK");
        }else if(loose_route()){
                ##
                ## If we are in-dialog loose_route() should return true and we should
                ## end up here.  I am not sure the subsequent check of has_totag() is
                ## necessary, but I could be wrong.
                ##
                xlog("L_INFO", "Loose route has returned true, attempting routing.\n");
               
                if(!has_totag()){
                        xlog("L_INFO", "Initial loose-route rejected\n");
                        t_reply("403","Initial Loose-Routing Rejected.");
                        exit;
                }

                route(2);
        }else{
                ##
                ## In theory we shouldn't get here as anything that isn't an INVITE
                ## or an OPTIONS should be routed via the loose_route condition.
                ## I suppose there may be a timing issue where we need to account for a
                ## CANCEL request and forward it along.
                ##
                if(is_method("CANCEL") || is_method("ACK")){
                        xlog("L_INFO", "We have an ACK or CANCEL");
                        route(3);
                }
        }
}



########################################################################
## Handles relay of INVITE messages
## with round-robin load balancing
##
## We select the next from the dispatcher
## using simple round-robin algorithm.
########################################################################
route[1]{
        ds_select_domain("1","4");
        t_on_reply("1");
        t_on_failure("1");
        t_relay();
}



########################################################################
## Handles relay of all non INVITE messages
##
## All messages which were routed via the loose_route
## condition will end up here.  If there is a message that fails
## to t_rely there probably isn't much we can do other than
## return an error.
########################################################################
route[2]{
        xlog("L_INFO", "Setting up reply handler and relaying request\n");
        t_on_reply("1");
        if(!t_relay()){
                sl_reply_error();
        }
}


########################################################################
## Handles relay of CANCEL or ACK messages
########################################################################
route[3]{
        t_on_reply("1");
        if(t_check_trans()){
                if(!t_relay()){
                        xlog("L_INFO","Error relaying message route[3]\n");
                        sl_reply_error();
                }
        }else{
                xlog("L_INFO","Dropping mis-routed request from route[3]\n");
               
        }
        exit;
}



#######################################################################
## Simply logs responses
#######################################################################
onreply_route[1]{
        xlog("L_INFO", "Reply - S=$rs D=$rr F=$fu T=$tu IP=$si ID=$ci\n");
        exit;
}



#######################################################################
## Handles failure of INVITE forwarding
#######################################################################
failure_route[1]{
        xlog("L_INFO","Failure route, trying again\n");

        if(t_check_status("408")){
                xlog("L_INFO","Got a 408 Timeout, flagging dest as invalid\n");
                ds_mark_dst();
                route(1);
        }else{
                if(t_was_cancelled()){
                        xlog("L_INFO","Recieved a 4XX error for a cancelled transaction");
                        exit;
                }else if(!t_relay()){
                        xlog("L_INFO","Error relaying error message");
                        exit;
                }
        }
}


On Wed, Feb 11, 2009 at 4:43 PM, Iñaki Baz Castillo <[hidden email]> wrote:

> El Miércoles, 11 de Febrero de 2009, Geoffrey Mina escribió:
>> It's nice to see there are actually some folks out there who can
>> (almost) see where I am coming from.  The general response of the
>> community is quite surprising.  I was expecting much different
>> responses based on the level of support specific questions receive
>> when submitted.
>>
>> My system is working 100% error free in the 'lab' environment, so
>> hopefully you are correct in your assumption that I have achieved
>> success.
>>
>> I have heard everyone LOUD and CLEAR.  Unless it's broken or not
>> working as expected... don't come here looking for advice and
>> mentoring!
>
> Please paste your configuration (better if you attach it as text file) and
> make a description of what it's supposed to do. Detail also in which points
> you could have some doubt.
>
> You didn't understand us (better if I speak just about me). I'm ready to help
> if I read a good and detailed description. What I don't like is the way you
> initiated your request, very honest, but unfeasible in fact (IMHO).
>
> So please, let's help you in a more feasible way :)
>
>
>
> --
> Iñaki Baz Castillo
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

opensips.cfg.txt (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Iñaki Baz Castillo
In reply to this post by Geoffrey Mina
I don't understand the following:


-----------------------------------------------
########################################################################
## Handles relay of INVITE messages
## with round-robin load balancing
########################################################################
route[1]{
        ds_select_domain("1","4");
        t_on_reply("1");
        t_on_failure("1");
        t_relay();
}

[...]

#######################################################################
## Handles failure of INVITE forwarding
#######################################################################
failure_route[1]{
        xlog("L_INFO","Failure route, trying again\n");

        if(t_check_status("408")){
                xlog("L_INFO","Got a 408 Timeout, flagging dest as invalid\n");
                ds_mark_dst();
                route(1);
----------------------------------------------


In failure_route[1] you call route[1], and in route[1] you
execute "ds_select_domain()".
According to the doc:
  http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id271282
"ds_select_domain()" can only be called from REQUEST_ROUTE, and not from
FAILURE_ROUTE.
I wonder why you don't get an error when starting your OpenSIPS. ¿?

I expect you should use "ds_next_domain" in FAILURE_ROUTE:
  http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id271328

Are you 100% sure that this script works in your lab? How have you simulated
the "408" from a server?


Other point: you consider the case of a 408 to dissable a gateway. I've worked
with OpenSIPS in front of an Asterisk acting as PSTN gateway using PRI.
Sometimes, when the PSTN called doesn't answer after XX seconds, the telco
replies a ISUP code that Asterisk converts to "408". Be careful because if
that occurs your OpenSIPS will mark that Asterisk as "dead".


Other point: why do you only consider 408 to dissable a gateway? Imagine that
the Asterisk has a problem and replies 500 (Internal Error) or 503. But if
you add those casees, be sure of adding "Hangup" at the end of each possible
extension in your Asterisk dialplan. If not, Asterisk will reply 503.



 



--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Iñaki Baz Castillo
In reply to this post by Geoffrey Mina
El Miércoles, 11 de Febrero de 2009, Geoffrey Mina escribió:
>  ## If we are in-dialog loose_route() should return true and we should
>  ## end up here.  I am not sure the subsequent check of has_totag() is
>  ## necessary, but I could be wrong.

Yes, you should do it. In your actual config, if an in-dialog request (To tag)
with no Route headers arrives, your OpenSIPS will accept it (loose_route
returns false since there is no Route headers).

An in-dialog request with no Route header should never arrive toa proxy, since
a proxy only remains in the dialog path if it added Record-Route header, so
in-dialog requests would have Route header. If not, they are invalid/spoofed.


--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Geoffrey Mina
In reply to this post by Iñaki Baz Castillo
Thanks for the input.  I did test the 408 scenario by disabling one of
the asterisk systems.  I was connected properly and the one end point
was removed from the pool.  I will run some more tests and analyze the
debug info more carefully to see exactly what path is being taken.

In regards to asterisk as a PSTN gateway, it isn't acting as such, so
I don't have to worry about that.  The systems are simply providing
end point IVR functionality.  Asterisk will ALWAYS answer the call
itself.

I will definitely add the 500 and 600 series errors to my failover handling.

Excellent Input!!!

Much appreciated.

On Wed, Feb 11, 2009 at 5:10 PM, Iñaki Baz Castillo <[hidden email]> wrote:

> I don't understand the following:
>
>
> -----------------------------------------------
> ########################################################################
> ## Handles relay of INVITE messages
> ## with round-robin load balancing
> ########################################################################
> route[1]{
>        ds_select_domain("1","4");
>        t_on_reply("1");
>        t_on_failure("1");
>        t_relay();
> }
>
> [...]
>
> #######################################################################
> ## Handles failure of INVITE forwarding
> #######################################################################
> failure_route[1]{
>        xlog("L_INFO","Failure route, trying again\n");
>
>        if(t_check_status("408")){
>                xlog("L_INFO","Got a 408 Timeout, flagging dest as invalid\n");
>                ds_mark_dst();
>                route(1);
> ----------------------------------------------
>
>
> In failure_route[1] you call route[1], and in route[1] you
> execute "ds_select_domain()".
> According to the doc:
>  http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id271282
> "ds_select_domain()" can only be called from REQUEST_ROUTE, and not from
> FAILURE_ROUTE.
> I wonder why you don't get an error when starting your OpenSIPS. ¿?
>
> I expect you should use "ds_next_domain" in FAILURE_ROUTE:
>  http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id271328
>
> Are you 100% sure that this script works in your lab? How have you simulated
> the "408" from a server?
>
>
> Other point: you consider the case of a 408 to dissable a gateway. I've worked
> with OpenSIPS in front of an Asterisk acting as PSTN gateway using PRI.
> Sometimes, when the PSTN called doesn't answer after XX seconds, the telco
> replies a ISUP code that Asterisk converts to "408". Be careful because if
> that occurs your OpenSIPS will mark that Asterisk as "dead".
>
>
> Other point: why do you only consider 408 to dissable a gateway? Imagine that
> the Asterisk has a problem and replies 500 (Internal Error) or 503. But if
> you add those casees, be sure of adding "Hangup" at the end of each possible
> extension in your Asterisk dialplan. If not, Asterisk will reply 503.
>
>
>
>
>
>
>
> --
> Iñaki Baz Castillo
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Brett Nemeroff
In reply to this post by Iñaki Baz Castillo
That 408 doesn't make sense to me.. 

If you got a 408 back, the gateway you are sending to WORKS, but IT'S destination is failing.

say for example you send to a gateway and that gateway sends to 10 different providers.. if this call routes to provider A, which doesn't respond, then your gateway may respond back with a 408. Where the failure isn't your gateway, it's your gateway's upstream..
-Brett


On Wed, Feb 11, 2009 at 4:10 PM, Iñaki Baz Castillo <[hidden email]> wrote:
I don't understand the following:


-----------------------------------------------
########################################################################
## Handles relay of INVITE messages
## with round-robin load balancing
########################################################################
route[1]{
       ds_select_domain("1","4");
       t_on_reply("1");
       t_on_failure("1");
       t_relay();
}

[...]

#######################################################################
## Handles failure of INVITE forwarding
#######################################################################
failure_route[1]{
       xlog("L_INFO","Failure route, trying again\n");

       if(t_check_status("408")){
               xlog("L_INFO","Got a 408 Timeout, flagging dest as invalid\n");
               ds_mark_dst();
               route(1);
----------------------------------------------


In failure_route[1] you call route[1], and in route[1] you
execute "ds_select_domain()".
According to the doc:
 http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id271282
"ds_select_domain()" can only be called from REQUEST_ROUTE, and not from
FAILURE_ROUTE.
I wonder why you don't get an error when starting your OpenSIPS. ¿?

I expect you should use "ds_next_domain" in FAILURE_ROUTE:
 http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id271328

Are you 100% sure that this script works in your lab? How have you simulated
the "408" from a server?


Other point: you consider the case of a 408 to dissable a gateway. I've worked
with OpenSIPS in front of an Asterisk acting as PSTN gateway using PRI.
Sometimes, when the PSTN called doesn't answer after XX seconds, the telco
replies a ISUP code that Asterisk converts to "408". Be careful because if
that occurs your OpenSIPS will mark that Asterisk as "dead".


Other point: why do you only consider 408 to dissable a gateway? Imagine that
the Asterisk has a problem and replies 500 (Internal Error) or 503. But if
you add those casees, be sure of adding "Hangup" at the end of each possible
extension in your Asterisk dialplan. If not, Asterisk will reply 503.







--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Alex Balashov
In reply to this post by Geoffrey Mina
Geoffrey Mina wrote:

> I generally don't like to presume that individuals want to
> help me Pro Bono

But we do it all day.

When you ask the question in $300 terms, you make it a $300 issue.

When you ask a question, you make it into a compelling challenge for
those who love to help others in the community.

--
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Iñaki Baz Castillo
In reply to this post by Brett Nemeroff
El Miércoles, 11 de Febrero de 2009, Brett Nemeroff escribió:
> That 408 doesn't make sense to me.. 
>
> If you got a 408 back, the gateway you are sending to WORKS, but IT'S
> destination is failing.

That's incorrect. RFC 3261 states clearly that, in case a request has no reply
(after the corresponding retransmissions) then the transaction client
(OpenSIPS in this case) MUST generate *internally* a 408 response. In case
there is just one branch, OpenSIPS must send that 408 upstream as definitive
negative response. And sure this is the behaviour.


> say for example you send to a gateway and that gateway sends to 10
> different providers.. if this call routes to provider A, which doesn't
> respond, then your gateway may respond back with a 408. Where the failure
> isn't your gateway, it's your gateway's upstream..

That's a more complex scenario. But you are rigth, it's not easy to choose the
appropiate response code since any node in the signalling path could generate
that response.



--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Geoffrey Mina
In reply to this post by Brett Nemeroff
Brett,
The 408 in this scenario is generated by OpenSIPS internally.  As
discussed previously, these systems are simply acting as IVR end
points.  They ALWAYS answer the call.  It is not dependant on anything
upstream or outside of the Asterisk server.  If OpenSIPS generates an
internal timeout... I know for a fact that my server has failed.  My
server will never provide a 408 in it's configuration.  The first
thing in my dialplan is a call to Answer().  Remember, this is a very
specific scenario deployment, so I can really narrow down what I need
to account for.

Thanks,
Geoff



On Wed, Feb 11, 2009 at 5:38 PM, Brett Nemeroff <[hidden email]> wrote:

> That 408 doesn't make sense to me..
> If you got a 408 back, the gateway you are sending to WORKS, but IT'S
> destination is failing.
> say for example you send to a gateway and that gateway sends to 10 different
> providers.. if this call routes to provider A, which doesn't respond, then
> your gateway may respond back with a 408. Where the failure isn't your
> gateway, it's your gateway's upstream..
> -Brett
>
> On Wed, Feb 11, 2009 at 4:10 PM, Iñaki Baz Castillo <[hidden email]> wrote:
>>
>> I don't understand the following:
>>
>>
>> -----------------------------------------------
>> ########################################################################
>> ## Handles relay of INVITE messages
>> ## with round-robin load balancing
>> ########################################################################
>> route[1]{
>>        ds_select_domain("1","4");
>>        t_on_reply("1");
>>        t_on_failure("1");
>>        t_relay();
>> }
>>
>> [...]
>>
>> #######################################################################
>> ## Handles failure of INVITE forwarding
>> #######################################################################
>> failure_route[1]{
>>        xlog("L_INFO","Failure route, trying again\n");
>>
>>        if(t_check_status("408")){
>>                xlog("L_INFO","Got a 408 Timeout, flagging dest as
>> invalid\n");
>>                ds_mark_dst();
>>                route(1);
>> ----------------------------------------------
>>
>>
>> In failure_route[1] you call route[1], and in route[1] you
>> execute "ds_select_domain()".
>> According to the doc:
>>  http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id271282
>> "ds_select_domain()" can only be called from REQUEST_ROUTE, and not from
>> FAILURE_ROUTE.
>> I wonder why you don't get an error when starting your OpenSIPS. ¿?
>>
>> I expect you should use "ds_next_domain" in FAILURE_ROUTE:
>>  http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id271328
>>
>> Are you 100% sure that this script works in your lab? How have you
>> simulated
>> the "408" from a server?
>>
>>
>> Other point: you consider the case of a 408 to dissable a gateway. I've
>> worked
>> with OpenSIPS in front of an Asterisk acting as PSTN gateway using PRI.
>> Sometimes, when the PSTN called doesn't answer after XX seconds, the telco
>> replies a ISUP code that Asterisk converts to "408". Be careful because if
>> that occurs your OpenSIPS will mark that Asterisk as "dead".
>>
>>
>> Other point: why do you only consider 408 to dissable a gateway? Imagine
>> that
>> the Asterisk has a problem and replies 500 (Internal Error) or 503. But if
>> you add those casees, be sure of adding "Hangup" at the end of each
>> possible
>> extension in your Asterisk dialplan. If not, Asterisk will reply 503.
>>
>>
>>
>>
>>
>>
>>
>> --
>> Iñaki Baz Castillo
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Iñaki Baz Castillo
In reply to this post by Geoffrey Mina
El Miércoles, 11 de Febrero de 2009, Geoffrey Mina escribió:
> Thanks for the input.  I did test the 408 scenario by disabling one of
> the asterisk systems.  I was connected properly and the one end point
> was removed from the pool.  I will run some more tests and analyze the
> debug info more carefully to see exactly what path is being taken.

Yes, in case there is no UDP response, after 32 seconds (T1 timer), OpenSIPS
will generate internally a 408 response.


> In regards to asterisk as a PSTN gateway, it isn't acting as such, so
> I don't have to worry about that.  The systems are simply providing
> end point IVR functionality.  Asterisk will ALWAYS answer the call
> itself.

Easier then :)


> I will definitely add the 500 and 600 series errors to my failover
> handling.

I see no reason for including 6XX errors, they are "normal" negative responses
instead of "errors".


> Excellent Input!!!

I would insist on the "ds_select_domain" usage in FAILURE_ROUTE which I think
is wrong.

Regards.


--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Geoffrey Mina
In reply to this post by Iñaki Baz Castillo
I have taken your initial suggestions and mofied by deployment.  You
were a great help in assisting me to see some loop holes in my
configuration.

The updated configuration, based on your suggestions is attached.
There is also a debug=10 trace attached for both a scenario where my
asterisk server was shutdown (read: internal 408 response) and one
where my server answered properly.  It appears the failover
routing/marking is working as desired.

(Community) Thank you much for your engagement here.  I understand we
got off to a rocky start :)

-Geoff

On Wed, Feb 11, 2009 at 5:20 PM, Iñaki Baz Castillo <[hidden email]> wrote:

> El Miércoles, 11 de Febrero de 2009, Geoffrey Mina escribió:
>>  ## If we are in-dialog loose_route() should return true and we should
>>  ## end up here.  I am not sure the subsequent check of has_totag() is
>>  ## necessary, but I could be wrong.
>
> Yes, you should do it. In your actual config, if an in-dialog request (To tag)
> with no Route headers arrives, your OpenSIPS will accept it (loose_route
> returns false since there is no Route headers).
>
> An in-dialog request with no Route header should never arrive toa proxy, since
> a proxy only remains in the dialog path if it added Record-Route header, so
> in-dialog requests would have Route header. If not, they are invalid/spoofed.
>
>
> --
> Iñaki Baz Castillo
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

dispatcher-timeout-trace.txt (3K) Download Attachment
opensips.cfg (9K) Download Attachment
dispatcher-success.txt (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Iñaki Baz Castillo
In reply to this post by Iñaki Baz Castillo
El Jueves, 12 de Febrero de 2009, escribió:
> I have addressed the ds_select_domain() usage issue after re-reading
> the documentation upon your guidance.  The last config I sent over is
> using ds_next_dst() in the failure_route.
>
> I am not sure why OpenSIPS didn't have a startup error, but it
> appeared to have started cleanly...

As you can see in module "dispatcher.c":

  {"ds_select_domain", (cmd_function)w_ds_select_domain, 2, fixup_igp_igp, 0,
REQUEST_ROUTE},

So "ds_select_domain" can be invoked just in REQUEST_ROUTE. I'm suspecting
that since the funcion is called into a ROUTE block (called from a
FAILURE_ROUTE block) the check is "bypassed". I'd consider it a bug...

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Geoffrey Mina
Either a 'bug' or a 'feature'... whatever you want to call it :)  It
worked as I _expected_, but not as intended.

thanks,
Geoff

On Wed, Feb 11, 2009 at 6:18 PM, Iñaki Baz Castillo <[hidden email]> wrote:

> El Jueves, 12 de Febrero de 2009, escribió:
>> I have addressed the ds_select_domain() usage issue after re-reading
>> the documentation upon your guidance.  The last config I sent over is
>> using ds_next_dst() in the failure_route.
>>
>> I am not sure why OpenSIPS didn't have a startup error, but it
>> appeared to have started cleanly...
>
> As you can see in module "dispatcher.c":
>
>  {"ds_select_domain", (cmd_function)w_ds_select_domain, 2, fixup_igp_igp, 0,
> REQUEST_ROUTE},
>
> So "ds_select_domain" can be invoked just in REQUEST_ROUTE. I'm suspecting
> that since the funcion is called into a ROUTE block (called from a
> FAILURE_ROUTE block) the check is "bypassed". I'd consider it a bug...
>
> --
> Iñaki Baz Castillo
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Norman Brandinger
There have been a couple of people (myself included) that have taken
advantage of this 'bug' / 'feature'.  Probably should get some input
from Bogdan as to whether it's something to be used or avoided.

Regards,
Norm

Geoffrey Mina wrote:

> Either a 'bug' or a 'feature'... whatever you want to call it :)  It
> worked as I _expected_, but not as intended.
>
> thanks,
> Geoff
>
> On Wed, Feb 11, 2009 at 6:18 PM, Iñaki Baz Castillo <[hidden email]> wrote:
>  
>> El Jueves, 12 de Febrero de 2009, escribió:
>>    
>>> I have addressed the ds_select_domain() usage issue after re-reading
>>> the documentation upon your guidance.  The last config I sent over is
>>> using ds_next_dst() in the failure_route.
>>>
>>> I am not sure why OpenSIPS didn't have a startup error, but it
>>> appeared to have started cleanly...
>>>      
>> As you can see in module "dispatcher.c":
>>
>>  {"ds_select_domain", (cmd_function)w_ds_select_domain, 2, fixup_igp_igp, 0,
>> REQUEST_ROUTE},
>>
>> So "ds_select_domain" can be invoked just in REQUEST_ROUTE. I'm suspecting
>> that since the funcion is called into a ROUTE block (called from a
>> FAILURE_ROUTE block) the check is "bypassed". I'd consider it a bug...
>>
>> --
>> Iñaki Baz Castillo
>>
>>    
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Brett Nemeroff
In reply to this post by Iñaki Baz Castillo
Ah, I see.. I totally forgot about an internally generated 408. I was just trying to suggest that if you receive a 408 from an endpoint, it isn't necessarily grounds for being blacklisted. However, given the application, it probably makes sense.



On Wed, Feb 11, 2009 at 5:04 PM, Iñaki Baz Castillo <[hidden email]> wrote:
El Miércoles, 11 de Febrero de 2009, Brett Nemeroff escribió:
> That 408 doesn't make sense to me.. 
>
> If you got a 408 back, the gateway you are sending to WORKS, but IT'S
> destination is failing.

That's incorrect. RFC 3261 states clearly that, in case a request has no reply
(after the corresponding retransmissions) then the transaction client
(OpenSIPS in this case) MUST generate *internally* a 408 response. In case
there is just one branch, OpenSIPS must send that 408 upstream as definitive
negative response. And sure this is the behaviour.


> say for example you send to a gateway and that gateway sends to 10
> different providers.. if this call routes to provider A, which doesn't
> respond, then your gateway may respond back with a 408. Where the failure
> isn't your gateway, it's your gateway's upstream..

That's a more complex scenario. But you are rigth, it's not easy to choose the
appropiate response code since any node in the signalling path could generate
that response.



--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Bogdan-Andrei Iancu
In reply to this post by Norman Brandinger
Hi everybody,

Norman Brandinger wrote:
> The old OpenSER/Kamailio site has a "business" mailing list that is
> dedicated to this type of topic.  Seems like a good idea to create a
> similar mailing list for the OpenSIPS folks.
>  
Just as a completion - Norm, thanks for your suggestion - I did created
such a mailing list and even more a business web page on the web site. See:
         
http://lists.opensips.org/pipermail/users/2009-February/003145.html

Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Geoffrey Mina
Well, just figured I would provide an update.  As I was very put off
by the general attitude of the community as it related to my request
for commercial support and assistance during my deployment phase I
started looking elsewhere.

Someone on this list suggested I contact the author of the dispatcher
module (Daniel-Constantin Mierla).  He was very responsive to my
initial request and we quickly came upon an hourly consulting
agreement through his company Asipto based in Romania.

On top of that, I have decided to replace my OpenSIPS install with
Kamailio based on some conversations I had with Daniel.  I think I
will be much happier in my new 'home', where I don't have to worry
about getting flamed while looking for some professional consulting
services.  As the individual responsible for seeing that the calls
coming into my network are properly handled, it makes me comfortable
to know I have a professional resource as opposed to simply a user
list (which is often very helpful)

Bogdan - I would like to personally thank you for addressing some of
my questions personally over the last couple of months.  You helped me
greatly in getting past some of the initial learning curve issues
associated with the OpenSIPS project.

Thanks, and take care.
Geoff



On Thu, Feb 12, 2009 at 7:03 AM, Bogdan-Andrei Iancu
<[hidden email]> wrote:

> Hi everybody,
>
> Norman Brandinger wrote:
>>
>> The old OpenSER/Kamailio site has a "business" mailing list that is
>> dedicated to this type of topic.  Seems like a good idea to create a similar
>> mailing list for the OpenSIPS folks.
>>
>
> Just as a completion - Norm, thanks for your suggestion - I did created such
> a mailing list and even more a business web page on the web site. See:
>         http://lists.opensips.org/pipermail/users/2009-February/003145.html
>
> Regards,
> Bogdan
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Bogdan-Andrei Iancu
Hi Geoffrey,

I'm sorry for the outcome, but I think you are missing the most
important aspect here:

nobody was flaming or reluctant to offer you support - but reviewing a
production script from 0 in 2 hours it is fantasy job. That was what all
the people tried to explain you.

I, as a consultant, wouldn't compromise the quality of my work in order
to do a best effort jobs - to do the best in reviewing a totally new
production script in couple of hours. Last time when I did something
similar, it took 2 days!

So, bottom line, nobody wanted to commit for something that cannot be
done. Nobody wanted to do a lauzy job just to take your money. Because
what you were requesting was not possible - that was the only issue.


Anyhow, you lost the opportunity to use a real load-balancer module
(with load monitoring and call tracking) for your platform :P..

Regards,
Bogdan



Geoffrey Mina wrote:

> Well, just figured I would provide an update.  As I was very put off
> by the general attitude of the community as it related to my request
> for commercial support and assistance during my deployment phase I
> started looking elsewhere.
>
> Someone on this list suggested I contact the author of the dispatcher
> module (Daniel-Constantin Mierla).  He was very responsive to my
> initial request and we quickly came upon an hourly consulting
> agreement through his company Asipto based in Romania.
>
> On top of that, I have decided to replace my OpenSIPS install with
> Kamailio based on some conversations I had with Daniel.  I think I
> will be much happier in my new 'home', where I don't have to worry
> about getting flamed while looking for some professional consulting
> services.  As the individual responsible for seeing that the calls
> coming into my network are properly handled, it makes me comfortable
> to know I have a professional resource as opposed to simply a user
> list (which is often very helpful)
>
> Bogdan - I would like to personally thank you for addressing some of
> my questions personally over the last couple of months.  You helped me
> greatly in getting past some of the initial learning curve issues
> associated with the OpenSIPS project.
>
> Thanks, and take care.
> Geoff
>
>
>
> On Thu, Feb 12, 2009 at 7:03 AM, Bogdan-Andrei Iancu
> <[hidden email]> wrote:
>  
>> Hi everybody,
>>
>> Norman Brandinger wrote:
>>    
>>> The old OpenSER/Kamailio site has a "business" mailing list that is
>>> dedicated to this type of topic.  Seems like a good idea to create a similar
>>> mailing list for the OpenSIPS folks.
>>>
>>>      
>> Just as a completion - Norm, thanks for your suggestion - I did created such
>> a mailing list and even more a business web page on the web site. See:
>>         http://lists.opensips.org/pipermail/users/2009-February/003145.html
>>
>> Regards,
>> Bogdan
>>
>>    
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

John Rose
In reply to this post by Geoffrey Mina
I'm on SER, Kamalilo and OpenSIPS mailing lists. This is by far the most
lively list. Kamalilo list is dead as far as I can see... Also, if you ask a
question on the SER list you often get dead air though that list is good for
historical quantity and quality.

John


> From: [hidden email] [mailto:users-
> Subject: Re: [OpenSIPS-Users] Paid Consultation Request
>
> Well, just figured I would provide an update.  As I was very put off
> by the general attitude of the community as it related to my request
> for commercial support and assistance during my deployment phase I
> started looking elsewhere.
>
> Someone on this list suggested I contact the author of the dispatcher
> module (Daniel-Constantin Mierla).  He was very responsive to my
> initial request and we quickly came upon an hourly consulting
> agreement through his company Asipto based in Romania.
>
> On top of that, I have decided to replace my OpenSIPS install with
> Kamailio based on some conversations I had with Daniel.  I think I
> will be much happier in my new 'home', where I don't have to worry
> about getting flamed while looking for some professional consulting
> services.  As the individual responsible for seeing that the calls
> coming into my network are properly handled, it makes me comfortable
> to know I have a professional resource as opposed to simply a user
> list (which is often very helpful)
>
> Bogdan - I would like to personally thank you for addressing some of
> my questions personally over the last couple of months.  You helped me
> greatly in getting past some of the initial learning curve issues
> associated with the OpenSIPS project.
>
> Thanks, and take care.
> Geoff
>
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Iñaki Baz Castillo
2009/2/12 John Rose <[hidden email]>:
> I'm on SER, Kamalilo and OpenSIPS mailing lists. This is by far the most
> lively list. Kamalilo list is dead as far as I can see...

Kamailio list is really far from being dead. It has more or less the
same traffic as OpenSIPS list. Both are alive.


--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Paid Consultation Request

Brett Nemeroff
In reply to this post by Bogdan-Andrei Iancu
Geoffrey,
You shouldn't be put off by everyone's responses. Keep in mind that all of us out here took time to respond to you. Which should be an indicator of the willingness of everyone to help. Not everyone will have a gentle demeanor, but the basic point is that what you were asking for suggested you didn't know what was wrong, but you did know how long it would take to fix.  Us as developers look at that and think that it's unlikely that we'll be able to meet those needs and make you happy.

I would be happy to help you out, as I'm sure plenty on this list would be. But I'm certain that a couple hours isn't going to get you much. 

I wouldn't give up on the project because of this.. I'd step back and say, "Wow, look at all the people who wrote back to me". 

-Brett




On Thu, Feb 12, 2009 at 9:47 AM, Bogdan-Andrei Iancu <[hidden email]> wrote:
Hi Geoffrey,

I'm sorry for the outcome, but I think you are missing the most
important aspect here:

nobody was flaming or reluctant to offer you support - but reviewing a
production script from 0 in 2 hours it is fantasy job. That was what all
the people tried to explain you.

I, as a consultant, wouldn't compromise the quality of my work in order
to do a best effort jobs - to do the best in reviewing a totally new
production script in couple of hours. Last time when I did something
similar, it took 2 days!

So, bottom line, nobody wanted to commit for something that cannot be
done. Nobody wanted to do a lauzy job just to take your money. Because
what you were requesting was not possible - that was the only issue.


Anyhow, you lost the opportunity to use a real load-balancer module
(with load monitoring and call tracking) for your platform :P..

Regards,
Bogdan



Geoffrey Mina wrote:
> Well, just figured I would provide an update.  As I was very put off
> by the general attitude of the community as it related to my request
> for commercial support and assistance during my deployment phase I
> started looking elsewhere.
>
> Someone on this list suggested I contact the author of the dispatcher
> module (Daniel-Constantin Mierla).  He was very responsive to my
> initial request and we quickly came upon an hourly consulting
> agreement through his company Asipto based in Romania.
>
> On top of that, I have decided to replace my OpenSIPS install with
> Kamailio based on some conversations I had with Daniel.  I think I
> will be much happier in my new 'home', where I don't have to worry
> about getting flamed while looking for some professional consulting
> services.  As the individual responsible for seeing that the calls
> coming into my network are properly handled, it makes me comfortable
> to know I have a professional resource as opposed to simply a user
> list (which is often very helpful)
>
> Bogdan - I would like to personally thank you for addressing some of
> my questions personally over the last couple of months.  You helped me
> greatly in getting past some of the initial learning curve issues
> associated with the OpenSIPS project.
>
> Thanks, and take care.
> Geoff
>
>
>
> On Thu, Feb 12, 2009 at 7:03 AM, Bogdan-Andrei Iancu
> <[hidden email]> wrote:
>
>> Hi everybody,
>>
>> Norman Brandinger wrote:
>>
>>> The old OpenSER/Kamailio site has a "business" mailing list that is
>>> dedicated to this type of topic.  Seems like a good idea to create a similar
>>> mailing list for the OpenSIPS folks.
>>>
>>>
>> Just as a completion - Norm, thanks for your suggestion - I did created such
>> a mailing list and even more a business web page on the web site. See:
>>         http://lists.opensips.org/pipermail/users/2009-February/003145.html
>>
>> Regards,
>> Bogdan
>>
>>
>
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
123