Re: [OpenSIPS-Users] Asteriak load balance
Thanks. Could somebody share a simple config file using dispatcher module. Thanks Gonzo --- On Thu, 1/22/09, Iñaki Baz Castillo wrote: From: Iñaki Baz Castillo Subject: Re: [OpenSIPS-Users] Asteriak load balance To: gonzov...@yahoo.com Date: Thursday, January 22, 2009, 10:24 PM El Jueves, 22 de Enero de 2009, Gonzalo Gonzalez escribió: > What is the best module to use for load balance with 5 asterisk servers? > > user >> Opensips --->> Asterisk --->> PSTN Try dispacher module. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asteriak load balance
El Jueves, 22 de Enero de 2009, Gonzalo Gonzalez escribió: > What is the best module to use for load balance with 5 asterisk servers? > > user >> Opensips --->> Asterisk --->> PSTN Try dispacher module. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asteriak load balance
Dispatcher. Gonzalo Gonzalez wrote: > What is the best module to use for load balance with 5 asterisk servers? > > user >> Opensips --->> Asterisk --->> PSTN > > > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- 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 Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Asteriak load balance
What is the best module to use for load balance with 5 asterisk servers? user >> Opensips --->> Asterisk --->> PSTN ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] inbounts calls problems
Thanks a lot.
all is ok, and very good.
i will rewrite my script.
Iñaki Baz Castillo wrote:
>
> El Jueves, 22 de Enero de 2009, pjgonzalez escribió:
>> The user has 3 form to receive his inbount calls base on the following
>> preference:
>>
>> When the user is online:
>>
>> he can select one of the following state:
>>
>> 1-Receive his calls on his softphone.
>> 2-Forward his calls to another number on PSTN.
>>
>> when user is offline:
>>
>> sent his calls to voicemail.
>
>
> The problem is that you are using:
> if(!lookup("location")){
> and later select if you want the INVITE arrives to the registered user or
> to a
> PSTN number.
>
> But when a user is registered behind NAT and you do:
> lookup("location")
> then $du variavle is set containing the public IP of the registered
> contact.
> $du is the **REAL** destination of the request, even if you later modify
> the
> RURI.
>
> A workaround would be modifying $du if the user wants to receive the call
> in
> the PSTN number.
> But a more ellegant way is using "is_registered()" function that just
> returns
> true or false but doesn't set $du and doesn't modify $ru. This is:
>
> - INVITE received.
> - Do "is_registered()".
> - If true: route[13]
> - If false: voicemail
>
> in route[13]:
>
> - If the user wants to receive the INVITE then do: lookup("location").
> - If he prefers to receive in the PSTN phone then replace the RURI with
> the
> PSTN URI.
>
> Regards.
>
> PD: I suggest you to read about the $du variable in the OpenSIPS wiki
> (pseudo-variables section).
>
>
> --
> Iñaki Baz Castillo
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
--
View this message in context:
http://n2.nabble.com/inbounts-calls-problems-tp2197805p2200202.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Contributing to cdrtool
Hi Joan, See answers inline, On Jan 22, 2009, at 6:42 PM, Joan wrote: Good afternoon, I am trying to install cdrtool to an ubuntu 8.04, there are some problems I found so far: .- I'd prefer to build myself the .deb, so everything is on the right place whithout having to tweak everything by hand, but I cannot find the Makefile, makedeb, whatever, any doc explaining how to do it? Use debuild command .- I installed darcs client into my system. When doing the darcs get, I get the following: darcs failed: Not a repository: http://devel.ag-projects.com/repositories/cdrtool (Failed to download URL http://devel.ag-projects.com/repositories/cdrtool/_darcs/ inventory: HTTP response code said error) Fixed now, try again. .- Is the ticket system alive, there's only a single ticket nobody seem to care. Also I don't see the timeline part of the trac (where you can see the commits, changes to wiki, etc...)? http://cdrtool.ag-projects.com/timeline .- Is there any repository similar to the svnview so I can see the changes to the code through a web browser? http://cdrtool.ag-projects.com/browser .- Any place to contribute? Feel free to propose something on this mailing list. It seems to me that for the minimal installation (no radius server, no prepaid service), it's quite confusing having to enable everything Without a Radius setup CDRTool is pretty much useless. Adrian Kind regards ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] inbounts calls problems
El Jueves, 22 de Enero de 2009, pjgonzalez escribió:
> The user has 3 form to receive his inbount calls base on the following
> preference:
>
> When the user is online:
>
> he can select one of the following state:
>
> 1-Receive his calls on his softphone.
> 2-Forward his calls to another number on PSTN.
>
> when user is offline:
>
> sent his calls to voicemail.
The problem is that you are using:
if(!lookup("location")){
and later select if you want the INVITE arrives to the registered user or to a
PSTN number.
But when a user is registered behind NAT and you do:
lookup("location")
then $du variavle is set containing the public IP of the registered contact.
$du is the **REAL** destination of the request, even if you later modify the
RURI.
A workaround would be modifying $du if the user wants to receive the call in
the PSTN number.
But a more ellegant way is using "is_registered()" function that just returns
true or false but doesn't set $du and doesn't modify $ru. This is:
- INVITE received.
- Do "is_registered()".
- If true: route[13]
- If false: voicemail
in route[13]:
- If the user wants to receive the INVITE then do: lookup("location").
- If he prefers to receive in the PSTN phone then replace the RURI with the
PSTN URI.
Regards.
PD: I suggest you to read about the $du variable in the OpenSIPS wiki
(pseudo-variables section).
--
Iñaki Baz Castillo
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] inbounts calls problems
The user has 3 form to receive his inbount calls base on the following preference: When the user is online: he can select one of the following state: 1-Receive his calls on his softphone. 2-Forward his calls to another number on PSTN. when user is offline: sent his calls to voicemail. Iñaki Baz Castillo wrote: > > El Jueves, 22 de Enero de 2009, pjgonzalez escribió: >> Ok, >> >> Here the code. > > And which is the desired behaviour? > > -- > Iñaki Baz Castillo > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- View this message in context: http://n2.nabble.com/inbounts-calls-problems-tp2197805p2199838.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk Load Balancing with OpenSIPS + dispatcher
I am trying to translate the config file on the link from openser to opensips
1.4, but I am having an issue registering users, it looks like there is a loop,
but I don't know what am I doing wrong. I can make a call from a user account
to PSTN thru asterisk; I mean:
user >> opensips --->> asterisk --->> PSTN , but when I try to register the
user with opensips I get Registration error:483 Too Many Hops
This is my config:
# --- global configuration parameters
debug=3 # debug level (cmd line: -dd)
fork=yes
log_stderror=no # (cmd line: -E)
children=4
disable_tcp=yes
port=5060
# -- module loading --
#set module path
mpath="/usr/local/lib/opensips/modules/"
loadmodule "db_mysql.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "textops.so"
loadmodule "uri.so"
loadmodule "uri_db.so"
loadmodule "domain.so"
loadmodule "permissions.so"
loadmodule "group.so"
loadmodule "mi_fifo.so"
loadmodule "xlog.so"
loadmodule "avpops.so"
loadmodule "lcr.so"
# Uncomment this if you want digest authentication
# mysql.so must be loaded !
loadmodule "auth.so"
loadmodule "auth_db.so"
# - setting module-specific parameters ---
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")
modparam("usrloc", "db_mode", 2)
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
modparam("rr", "enable_full_lr", 1)
modparam("auth_db|permissions|uri_db|usrloc","db_url","mysql://opensips:opensip...@localhost/opensips")
modparam("permissions", "db_mode", 1)
modparam("permissions", "trusted_table", "trusted")
modparam("tm", "fr_timer",5)
modparam("tm", "fr_inv_timer_avp", "$avp(i:704)")
modparam("lcr","db_url","mysql://opensips:opensip...@localhost/opensips")
modparam("lcr","fr_inv_timer",90)
modparam("lcr","fr_inv_timer_next",30)
modparam("lcr", "fr_inv_timer_avp", "$avp(i:704)")
modparam("lcr", "gw_uri_avp", "$avp(i:709)")
modparam("lcr", "ruri_user_avp", "$avp(i:500)")
modparam("lcr", "contact_avp", "$avp(i:711)")
modparam("lcr", "rpid_avp", "$avp(i:302)")
modparam("lcr", "flags_avp", "$avp(i:712)")
#modparam("lcr", "dm_flag", 13)
# - request routing logic ---
# main routing logic
route{
# 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");
exit;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
# 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
if (!method=="REGISTER")
record_route();
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
};
if (!uri==myself) {
# mark routing logic in request
append_hf("P-hint: outbound\r\n");
route(1);
};
if (uri==myself) {
if (is_method("INVITE")) {
append_hf("P-hint: lcr applied\r\n");
# applying lcr routing
route(2);
};
};
route(1);
}
route[1] {
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
exit;
}
route[2] {
# load the gateways
if (!load_gws()) {
sl_send_reply("503", "Unable to load gateways");
exit;
} else {
$var(i) = 0;
#while($(avp(i:709)[$var(i)]) != null) {
while(is_avp_set("$(avp(i:709)[$var(i)])")) {
xlog("L_INFO", "loading
gw_uri_avp[$var(i)]='$(avp(i:709)[$var(i)])'\n");
$var(i) = $var(i) + 1;
};
if(is_avp_set("$avp(i:709)")) {
xlog("L_INFO", "trying gateway '$avp(i:709)'\n");
} else {
xlog("L_INFO", "no available gateways ...\n");
};
# try the first matched gateway
if (next_gw()) {
xlog("L_INFO", "ruri_user_avp='$avp(i:500)'\n");
# prepare for lcr failover
t_on_failure("2");
route(1);
} else {
sl_send_reply("503", "No available gateways");
exit;
};
};
exit;
}
failure_route[2] {
xlog("L_INFO", "entering failure_route[2] for reply code
'$T_reply_code'\n");
# the previous gateway is no good
if (t_check_status("408|50[34]")) {
if(is_avp_set("$avp(i:709)")) {
xlog("L_INFO", "trying next gateway '$avp(i:709)'\n");
} else {
xlog("L_INFO", "no
Re: [OpenSIPS-Users] inbounts calls problems
El Jueves, 22 de Enero de 2009, pjgonzalez escribió: > Ok, > > Here the code. And which is the desired behaviour? -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] inbounts calls problems
Ok,
Here the code.
#
# #
#Authentication and Authorization against a radius server. #
# #
#
route[1]{
sl_send_reply("100","Trying");
if (!radius_www_authorize("")){
www_challenge("", "0");
sl_send_reply("401","Unauthorized");
exit;
};
#
# #
# Check if register request was originated behind a NAT#
# and saved his IInformation to the location table #
# the setbflag with value 6 is identified the client #
# behind a NAT#
# #
#
if(!search("^Contact:[ ]*\*") && nat_uac_test("19"))
{
fix_nated_register();
setbflag(6);
}
if(!save("location"))
{
sl_reply_error();
exit;
}
exit;
}
# #
# INVITE MESSAGE HANDLER #
# #
route[2]{
if(nat_uac_test("19"))
{
setbflag(6);
force_rport();
fix_nated_contact();
};
if(!lookup("location")){
#SEND TO VOICE MAIL
AND OUTGOING CALLS
}
else
{
route(13); #CHECK THE PREFERENCE OF ONLINE USERS
}
}
##
##
# Call Forward#
##
##
route[11]
{
avp_pushto("$ru", "$avp(s:callForward)");
route(12);
exit;
}
route[12]{
t_on_reply("1");
if (!t_relay()) {
sl_reply_error();
};
exit;
}
###
# #
# ONLINE USER PREFERENCE LOGIC #
# #
###
route[13]
{
avp_db_load("$ru/username","*");
if(is_avp_set("$avp(s:callForward)"))
{
route(11);
exit;
}
#OTHER USER STATUS HANDLED HERE.
exit;
}
Iñaki Baz Castillo wrote:
>
> El Jueves, 22 de Enero de 2009, pjgonzalez escribió:
>> I do ti but right now the call only ring on the Softphone, User B.
>
> Sorry, but things are not so simple. You should provide a more detailed
> description of the desired behaviour, current behaviour and code.
>
> --
> Iñaki Baz Castillo
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
--
View this message in context:
http://n2.nabble.com/inbounts-calls-problems-tp2197805p2199510.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] inbounts calls problems
El Jueves, 22 de Enero de 2009, pjgonzalez escribió: > I do ti but right now the call only ring on the Softphone, User B. Sorry, but things are not so simple. You should provide a more detailed description of the desired behaviour, current behaviour and code. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] inbounts calls problems
I do ti but right now the call only ring on the Softphone, User B.
thanks.
Iñaki Baz Castillo wrote:
>
> 2009/1/22 pjgonzalez :
>>
>> hi every body, im having problems when in my inbounts calls when i try to
>> forward the calls: for example.
>>
>> USER A(PSTN USER) calls User B (Behind Nat) then the calls is forwarded
>> to
>> User C (ON PSTN).
>>
>> the problem is that the calls is ringing on user B and User C so when i
>> take
>> the call its drop and hangup.
>>
>> i'm doing that:
>>
>> avp_pushto("$ru", "$avp(s:callForward)");
>> append_branch();
>> route(1);
>>
>> route[1]{
>>
>>t_on_failure("1");
>>t_on_reply("1");
>>if (!t_relay()) {
>> sl_reply_error();
>>};
>>exit;
>> }
>
> If you do append_branch() then you are creating a new branch (ouh!) so
> you are creating parallel forking. It's logic that both B and C ring.
>
> --
> Iñaki Baz Castillo
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
--
View this message in context:
http://n2.nabble.com/inbounts-calls-problems-tp2197805p2199263.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Contributing to cdrtool
Good afternoon, I am trying to install cdrtool to an ubuntu 8.04, there are some problems I found so far: .- I'd prefer to build myself the .deb, so everything is on the right place whithout having to tweak everything by hand, but I cannot find the Makefile, makedeb, whatever, any doc explaining how to do it? .- I installed darcs client into my system. When doing the darcs get, I get the following: darcs failed: Not a repository: http://devel.ag-projects.com/repositories/cdrtool (Failed to download URL http://devel.ag-projects.com/repositories/cdrtool/_darcs/inventory: HTTP response code said error) .- Is the ticket system alive, there's only a single ticket nobody seem to care. Also I don't see the timeline part of the trac (where you can see the commits, changes to wiki, etc...)? .- Is there any repository similar to the svnview so I can see the changes to the code through a web browser? .- Any place to contribute? It seems to me that for the minimal installation (no radius server, no prepaid service), it's quite confusing having to enable everything Kind regards ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Include
Not only the cleverest, I think it's the best! I maintain the configuration for 12 SIP Proxies (using OpenSER) and I don't need 12 different configuration files. A number of macros transform one m4 file into one of 12 different configuration files with the stroke of a short command line. I'd be happy to help provide some help to get you started ... -Original Message- From: users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu Sent: Thursday, January 22, 2009 9:15 AM To: Matti Zemack Cc: users@lists.opensips.org Subject: Re: [OpenSIPS-Users] Include Hi Matti, no, there is no other solution - using M4 is the cleverest solution ;) Regards, Bogdan Matti Zemack wrote: > > Hi again, > > First of all, Thanks for all help I received previously today. > Fantastic and very quick response. > > So here is my second newbie-question: Is there any way to include > files at startup? It would be nice to split a 2000+ lines config file > into easier to handle parts. > > (After this morning tip from Iñaki, I suppose I could use m4 for this > errand... Any other clever suggestions?) > > Best Regards, > > Matti Zemack > > Stockholm > > Sweden > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] drouting module - dr_gateways table attrs field
Is there not a way to store in an AVP the gateway that was used in the call?
I have this need as well..-Brett
On Thu, Jan 22, 2009 at 9:44 AM, ibrahim tunali wrote:
> Hi Bogdan,
>
> I have already set attr avp like you sent. The problem occured when
> fill the attr field. If I leave blank attr field in DB it starts but
> when i set something like "gw1" it crashed.
>
> My db row;
>
>
> +--+--+---+---++---+-+
> | gwid | type | address | strip | pri_prefix | attrs |
> description |
>
> +--+--+---+---++---+-+
> |1 |1 | XX.XX.XXX.XX: | 0 | NULL | gw1 | main GW
> |
>
> +--+--+---+---++---+-+
>
> Crash dump;
>
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: 6
> columns returned from the query
> /usr/sbin/opensips[10261]: DBG:core:db_allocate_columns: allocate 48
> bytes for result names at 0x76a570
> /usr/sbin/opensips[10261]: DBG:core:db_allocate_columns: allocate 24
> bytes for result types at 0x76a5b0
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
> 16 bytes for RES_NAMES[0] at 0x76a5d8
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
> RES_NAMES(0x76a5d8)[0]=[gwid]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
> DB_INT result type
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
> 16 bytes for RES_NAMES[1] at 0x76a5f8
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
> RES_NAMES(0x76a5f8)[1]=[address]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
> DB_STRING result type
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
> 16 bytes for RES_NAMES[2] at 0x76a618
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
> RES_NAMES(0x76a618)[2]=[strip]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
> DB_INT result type
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
> 16 bytes for RES_NAMES[3] at 0x76a638
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
> RES_NAMES(0x76a638)[3]=[pri_prefix]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
> DB_STRING result type
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
> 16 bytes for RES_NAMES[4] at 0x76a658
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
> RES_NAMES(0x76a658)[4]=[type]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
> DB_INT result type
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
> 16 bytes for RES_NAMES[5] at 0x76a678
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
> RES_NAMES(0x76a678)[5]=[attrs]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
> DB_STRING result type
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_fetch_result:
> converting row 0 of 1 count 1
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_convert_row: allocate
> 192 bytes for row values at 0x76a6b8
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting INT
> [1]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting
> STRING [69.XX.XXX.55:]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting INT
> [0]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting INT
> [1]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting
> STRING [gw1]
> /usr/sbin/opensips[10261]: DBG:drouting:dr_load_routing_info: 1
> records found in dr_gateways
> /usr/sbin/opensips[10261]: DBG:drouting:add_dst: new gw ip addr
> [69.XX.XXX.55:]
> /usr/sbin/opensips[10249]: INFO:core:handle_sigs: child process 10261
> exited by a signal 11
> /usr/sbin/opensips[10267]: DBG:core:init_mod_child: type=CHILD,
> rank=4, module=registrar
> /usr/sbin/opensips[10249]: INFO:core:handle_sigs: core was not generated
> /usr/sbin/opensips[10267]: DBG:core:init_mod_child: type=CHILD,
> rank=4, module=group
> /usr/sbin/opensips[10249]: INFO:core:handle_sigs: terminating due to
> SIGCHLD
> /usr/sbin/opensips[10267]: INFO:core:sig_usr: signal 15 received
> /usr/sbin/opensips[10267]: Memory status (pkg):
> /usr/sbin/opensips[10273]: INFO:core:sig_usr: signal 15 received
> /usr/sbin/opensips[10273]: Memory status (pkg):
> /usr/sbin/opensips[10267]: fm_status (0x72bbe0):
>
> Regards,
>
> Ibrahim TUNALI
>
>
> On Thu, Jan 22, 2009 at 17:20, Bogdan-Andrei Iancu
> wrote:
> >
> > Hi Ibrahim,
> >
> > have you set the attr avp? Something like:
> > modparam("drouting", "attrs_avp", '$avp(s:dr_attrs)')
> >
> > Then after do_routing() or use_next_gw(), do :
> > xlog("-gw attr is $avp(s:dr_attrs)\n");
> >
> > the value of the attr is whatever you want - the module does not
> interpret it - it is just reading it from DB and pass it to the AVP when you
> use the GW. It is your deci
Re: [OpenSIPS-Users] drouting module - dr_gateways table attrs field
Hi Bogdan,
I tried now and opensips started without the problem. But i did not
get the value after calling "do_routing()".
I see NULL value on output of xlog;
"PSTN Termination RURI:9XX USER:XXX DOMAIN:sip.x.com
CARRIER:"
if(!do_routing()){
xlog("L_WARN","No drouting found");
sl_send_reply("404","PSTN Routing not found");
exit;
}
xlog("PSTN Termination RURI:$rU USER:$au DOMAIN:$ar
CARRIER:$avp(s:dr_attrs)\n");
Best Regards,
Ibrahim TUNALI
On Thu, Jan 22, 2009 at 17:57, Bogdan-Andrei Iancu
wrote:
> Hi Ibrahim,
>
> I found a bug related to what you described - I made a fix on SVN - please
> update and test again.
>
> Thanks and regards,
> Bogdan
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] drouting module - dr_gateways table attrs field
Hi Ibrahim,
I found a bug related to what you described - I made a fix on SVN -
please update and test again.
Thanks and regards,
Bogdan
ibrahim tunali wrote:
> Hi Bogdan,
>
> I have already set attr avp like you sent. The problem occured when
> fill the attr field. If I leave blank attr field in DB it starts but
> when i set something like "gw1" it crashed.
>
> My db row;
>
> +--+--+---+---++---+-+
> | gwid | type | address | strip | pri_prefix | attrs | description |
> +--+--+---+---++---+-+
> |1 |1 | XX.XX.XXX.XX: | 0 | NULL | gw1 | main GW |
> +--+--+---+---++---+-+
>
> Crash dump;
>
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: 6
> columns returned from the query
> /usr/sbin/opensips[10261]: DBG:core:db_allocate_columns: allocate 48
> bytes for result names at 0x76a570
> /usr/sbin/opensips[10261]: DBG:core:db_allocate_columns: allocate 24
> bytes for result types at 0x76a5b0
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
> 16 bytes for RES_NAMES[0] at 0x76a5d8
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
> RES_NAMES(0x76a5d8)[0]=[gwid]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
> DB_INT result type
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
> 16 bytes for RES_NAMES[1] at 0x76a5f8
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
> RES_NAMES(0x76a5f8)[1]=[address]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
> DB_STRING result type
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
> 16 bytes for RES_NAMES[2] at 0x76a618
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
> RES_NAMES(0x76a618)[2]=[strip]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
> DB_INT result type
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
> 16 bytes for RES_NAMES[3] at 0x76a638
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
> RES_NAMES(0x76a638)[3]=[pri_prefix]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
> DB_STRING result type
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
> 16 bytes for RES_NAMES[4] at 0x76a658
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
> RES_NAMES(0x76a658)[4]=[type]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
> DB_INT result type
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
> 16 bytes for RES_NAMES[5] at 0x76a678
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
> RES_NAMES(0x76a678)[5]=[attrs]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
> DB_STRING result type
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_fetch_result:
> converting row 0 of 1 count 1
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_convert_row: allocate
> 192 bytes for row values at 0x76a6b8
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting INT [1]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting
> STRING [69.XX.XXX.55:]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting INT [0]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting INT [1]
> /usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting
> STRING [gw1]
> /usr/sbin/opensips[10261]: DBG:drouting:dr_load_routing_info: 1
> records found in dr_gateways
> /usr/sbin/opensips[10261]: DBG:drouting:add_dst: new gw ip addr
> [69.XX.XXX.55:]
> /usr/sbin/opensips[10249]: INFO:core:handle_sigs: child process 10261
> exited by a signal 11
> /usr/sbin/opensips[10267]: DBG:core:init_mod_child: type=CHILD,
> rank=4, module=registrar
> /usr/sbin/opensips[10249]: INFO:core:handle_sigs: core was not generated
> /usr/sbin/opensips[10267]: DBG:core:init_mod_child: type=CHILD,
> rank=4, module=group
> /usr/sbin/opensips[10249]: INFO:core:handle_sigs: terminating due to SIGCHLD
> /usr/sbin/opensips[10267]: INFO:core:sig_usr: signal 15 received
> /usr/sbin/opensips[10267]: Memory status (pkg):
> /usr/sbin/opensips[10273]: INFO:core:sig_usr: signal 15 received
> /usr/sbin/opensips[10273]: Memory status (pkg):
> /usr/sbin/opensips[10267]: fm_status (0x72bbe0):
>
> Regards,
>
> Ibrahim TUNALI
>
>
> On Thu, Jan 22, 2009 at 17:20, Bogdan-Andrei Iancu
> wrote:
>
>> Hi Ibrahim,
>>
>> have you set the attr avp? Something like:
>> modparam("drouting", "attrs_avp", '$avp(s:dr_attrs)')
>>
>> Then after do_routing() or use_next_gw(), do :
>> xlog("-gw attr is $avp(s:dr_attrs)\n");
>>
>> the value of the attr is whatever you want - the module does not interpret
>> it - it is just reading it from DB and pass it to the AVP when you use the
>> GW. It is your decision what to put there an
Re: [OpenSIPS-Users] drouting module - dr_gateways table attrs field
Hi Bogdan,
I have already set attr avp like you sent. The problem occured when
fill the attr field. If I leave blank attr field in DB it starts but
when i set something like "gw1" it crashed.
My db row;
+--+--+---+---++---+-+
| gwid | type | address | strip | pri_prefix | attrs | description |
+--+--+---+---++---+-+
|1 |1 | XX.XX.XXX.XX: | 0 | NULL | gw1 | main GW |
+--+--+---+---++---+-+
Crash dump;
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: 6
columns returned from the query
/usr/sbin/opensips[10261]: DBG:core:db_allocate_columns: allocate 48
bytes for result names at 0x76a570
/usr/sbin/opensips[10261]: DBG:core:db_allocate_columns: allocate 24
bytes for result types at 0x76a5b0
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
16 bytes for RES_NAMES[0] at 0x76a5d8
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
RES_NAMES(0x76a5d8)[0]=[gwid]
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
DB_INT result type
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
16 bytes for RES_NAMES[1] at 0x76a5f8
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
RES_NAMES(0x76a5f8)[1]=[address]
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
DB_STRING result type
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
16 bytes for RES_NAMES[2] at 0x76a618
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
RES_NAMES(0x76a618)[2]=[strip]
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
DB_INT result type
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
16 bytes for RES_NAMES[3] at 0x76a638
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
RES_NAMES(0x76a638)[3]=[pri_prefix]
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
DB_STRING result type
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
16 bytes for RES_NAMES[4] at 0x76a658
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
RES_NAMES(0x76a658)[4]=[type]
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
DB_INT result type
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: allocate
16 bytes for RES_NAMES[5] at 0x76a678
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns:
RES_NAMES(0x76a678)[5]=[attrs]
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_get_columns: use
DB_STRING result type
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_fetch_result:
converting row 0 of 1 count 1
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_convert_row: allocate
192 bytes for row values at 0x76a6b8
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting INT [1]
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting
STRING [69.XX.XXX.55:]
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting INT [0]
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting INT [1]
/usr/sbin/opensips[10261]: DBG:db_mysql:db_mysql_str2val: converting
STRING [gw1]
/usr/sbin/opensips[10261]: DBG:drouting:dr_load_routing_info: 1
records found in dr_gateways
/usr/sbin/opensips[10261]: DBG:drouting:add_dst: new gw ip addr
[69.XX.XXX.55:]
/usr/sbin/opensips[10249]: INFO:core:handle_sigs: child process 10261
exited by a signal 11
/usr/sbin/opensips[10267]: DBG:core:init_mod_child: type=CHILD,
rank=4, module=registrar
/usr/sbin/opensips[10249]: INFO:core:handle_sigs: core was not generated
/usr/sbin/opensips[10267]: DBG:core:init_mod_child: type=CHILD,
rank=4, module=group
/usr/sbin/opensips[10249]: INFO:core:handle_sigs: terminating due to SIGCHLD
/usr/sbin/opensips[10267]: INFO:core:sig_usr: signal 15 received
/usr/sbin/opensips[10267]: Memory status (pkg):
/usr/sbin/opensips[10273]: INFO:core:sig_usr: signal 15 received
/usr/sbin/opensips[10273]: Memory status (pkg):
/usr/sbin/opensips[10267]: fm_status (0x72bbe0):
Regards,
Ibrahim TUNALI
On Thu, Jan 22, 2009 at 17:20, Bogdan-Andrei Iancu
wrote:
>
> Hi Ibrahim,
>
> have you set the attr avp? Something like:
> modparam("drouting", "attrs_avp", '$avp(s:dr_attrs)')
>
> Then after do_routing() or use_next_gw(), do :
> xlog("-gw attr is $avp(s:dr_attrs)\n");
>
> the value of the attr is whatever you want - the module does not interpret it
> - it is just reading it from DB and pass it to the AVP when you use the GW.
> It is your decision what to put there and how to use the value.
>
>
> Regards,
> Bogdan
>
> ibrahim tunali wrote:
>>
>> Hello,
>>
>> I'm playing with the new module drouting on svn trunk and i need to
>> get "which gateway is used on last request". I might be able to get it
>> with "attrs_avp" and "attrs" field on dr_gateways table, i guess. I
>> try some values to attrs but opensips crashed.
Re: [OpenSIPS-Users] drouting module - dr_gateways table attrs field
Hi Ibrahim,
have you set the attr avp? Something like:
modparam("drouting", "attrs_avp", '$avp(s:dr_attrs)')
Then after do_routing() or use_next_gw(), do :
xlog("-gw attr is $avp(s:dr_attrs)\n");
the value of the attr is whatever you want - the module does not interpret it -
it is just reading it from DB and pass it to the AVP when you use the GW. It is
your decision what to put there and how to use the value.
Regards,
Bogdan
ibrahim tunali wrote:
> Hello,
>
> I'm playing with the new module drouting on svn trunk and i need to
> get "which gateway is used on last request". I might be able to get it
> with "attrs_avp" and "attrs" field on dr_gateways table, i guess. I
> try some values to attrs but opensips crashed.
>
> Could you give an example to use attrs_avp and what is the value
> format of "attrs" fields.
>
> Regards,
>
> Ibrahim TUNALI
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Include
Hi Matti, no, there is no other solution - using M4 is the cleverest solution ;) Regards, Bogdan Matti Zemack wrote: > > Hi again, > > First of all, Thanks for all help I received previously today. > Fantastic and very quick response. > > So here is my second newbie-question: Is there any way to include > files at startup? It would be nice to split a 2000+ lines config file > into easier to handle parts. > > (After this morning tip from Iñaki, I suppose I could use m4 for this > errand… Any other clever suggestions?) > > Best Regards, > > Matti Zemack > > Stockholm > > Sweden > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] drouting module - dr_gateways table attrs field
Hello, I'm playing with the new module drouting on svn trunk and i need to get "which gateway is used on last request". I might be able to get it with "attrs_avp" and "attrs" field on dr_gateways table, i guess. I try some values to attrs but opensips crashed. Could you give an example to use attrs_avp and what is the value format of "attrs" fields. Regards, Ibrahim TUNALI ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Include
Hi again, First of all, Thanks for all help I received previously today. Fantastic and very quick response. So here is my second newbie-question: Is there any way to include files at startup? It would be nice to split a 2000+ lines config file into easier to handle parts. (After this morning tip from Iñaki, I suppose I could use m4 for this errand... Any other clever suggestions?) Best Regards, Matti Zemack Stockholm Sweden ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] inbounts calls problems
2009/1/22 pjgonzalez :
>
> hi every body, im having problems when in my inbounts calls when i try to
> forward the calls: for example.
>
> USER A(PSTN USER) calls User B (Behind Nat) then the calls is forwarded to
> User C (ON PSTN).
>
> the problem is that the calls is ringing on user B and User C so when i take
> the call its drop and hangup.
>
> i'm doing that:
>
> avp_pushto("$ru", "$avp(s:callForward)");
> append_branch();
> route(1);
>
> route[1]{
>
>t_on_failure("1");
>t_on_reply("1");
>if (!t_relay()) {
> sl_reply_error();
>};
>exit;
> }
If you do append_branch() then you are creating a new branch (ouh!) so
you are creating parallel forking. It's logic that both B and C ring.
--
Iñaki Baz Castillo
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Contents of ACK in up-to-date RFC 3261
Removes all of them. See:
http://www.opensips.org/html/docs/modules/1.4.x/textops.html#id271734
Regards,
Bogdan
Robert Borz wrote:
> Hi,
>
> so remove_hf("Proxy-Authorization") removes any Proxy-Authorization headers
> or just the first?
>
> What will happen if there are more than one proy auth. Header fields, will
> all of them be removed? This would be a solution... but I don't want to close
> our Sip proxy and only let outgoing and incoming sip calls of our domain go
> through.
>
> Hmm, I tried to add an radius_proxy_authorize() before the
> consume_credentials(), but as you said, I can't challenge ACKs and BYEs.
>
> Hmm
>
>
>
> -Original Message-
> From: bog...@voice-system.ro [mailto:bog...@voice-system.ro]
> Sent: Thursday, January 22, 2009 1:22 PM
> To: Robert Borz
> Cc: users@lists.opensips.org
> Subject: Re: [OpenSIPS-Users] Contents of ACK in up-to-date RFC 3261
>
> Hi Robert,
>
> I did read your email (even sent a reply ;))
>
> consume_credentials() function removes only credentials that were
> checked for authentication, so, in order to make it work, you have to
> previously do authentication. The function works in this way because a
> requests may contain credentials for multiple SIP proxies (chained
> authentication), so a proxy must be careful and remove only credentials
> targeting itself.
>
> So, what you you could do is to check if the ACK has the "Proxy-Auth"
> headers (with is_present_hf) and if so, use remove_hf() function to
> strip it out without any check.
>
> Regards,
> Bogdan
>
> Robert Borz wrote:
>
>> Hi Bogdan,
>>
>> thanks a lot for your response!
>>
>> So... you're exactly saying where I run into. ;)
>> Did you read my last mails with the subject "consume_credentials doesn't
>> work with auth_radius module"?
>>
>> Maybe you can help me just by telling me what's the way people do in
>> production.
>>
>> So... concerning my current configuration, I think I have the clue right
>> now, what the problem is.
>>
>> If an unauthorized INVITE comes in, my SER does radius_proxy_authorize() -
>> no problem here. But, to the 200 OK (Call answered), the ACK of my client
>> also contains the proxy authorization credentials, which is loose-routed.
>> And now, the is_present_hf("Proxy-Authorization") function returns true
>> (which is correct if the UAC includes the credentials in the ACK), but
>> consume_credentials() returns an error, because it doesn't know that it has
>> verified (and marked) the credentials before.
>>
>> How to proceed in this case
>>
>> -Original Message-
>> From: bog...@voice-system.ro [mailto:bog...@voice-system.ro]
>> Sent: Thursday, January 22, 2009 8:41 AM
>> To: Robert Borz
>> Cc: users@lists.opensips.org
>> Subject: Re: [OpenSIPS-Users] Contents of ACK in up-to-date RFC 3261
>>
>> Hi Robert,
>>
>> Robert Borz wrote:
>>
>>
>>> Just had a look at RFC 3261... 269 pages... well, looks for a hard work for
>>> one day... but it isn't written to understand and answer my dumb questions
>>> within one or two hours. ;)
>>>
>>>
>>>
>> indeed, the RFC3261 is like a novel :).
>>
>>
>>> So, just want to know which contents in an ACK message are allowed in which
>>> case...
>>>
>>> Especially, I'm interested in which contents in an ACK are allowed in a
>>> response to a 200 OK (after INVITE)... is the Proxy-Authorization header
>>> field allowed in an ACK as response to a 200 OK of an INVITE?
>>>
>>>
>>>
>> yes, it is optional - see the RFC3261, section 20.1 , page 163 - Table 3
>>
>>
>>> Maybe someone read my previous two mails, I'm a little confused right
>>> now...
>>>
>>> I detected different behaviour between different UACs, which is nothing
>>> unusual for me (I'm just a developer, too).
>>>
>>> X-Lite for example includes the digest-credentials in an ACK packet in the
>>> Proxy-Authorization header field, whereas the snom-softphone does not.
>>> The Ekige softphone for windows also includes the Proxy-Authorization
>>> header field.
>>>
>>> So, which behaviour is standard? It would be great to get any help from
>>> you... just to spare the time reading the whole RFC... :-(
>>>
>>>
>>>
>> well, all are correct, as the header presence in the ACK request is
>> optional
>>
>> My understanding on the RFC (on the auth matter) is that if the INVITE
>> has an "Proxy-Authorization" headers, the ACK should also contain
>> one...but it is not a must, it is a recommendation. The idea is, if the
>> proxy asked for auth for INVITE, it might ask for the ACK alsobut as
>> you cannot challenge the ACK, the client should pre-fill the auth in ACK.
>>
>> Regards,
>> Bogdan
>>
>>
>>> But, I don’t mind reading it... ;-P
>>>
>>>
>>> Robert.
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>
[OpenSIPS-Users] inbounts calls problems
hi every body, im having problems when in my inbounts calls when i try to
forward the calls: for example.
USER A(PSTN USER) calls User B (Behind Nat) then the calls is forwarded to
User C (ON PSTN).
the problem is that the calls is ringing on user B and User C so when i take
the call its drop and hangup.
i'm doing that:
avp_pushto("$ru", "$avp(s:callForward)");
append_branch();
route(1);
route[1]{
t_on_failure("1");
t_on_reply("1");
if (!t_relay()) {
sl_reply_error();
};
exit;
}
i'm using x-lite.
--
View this message in context:
http://n2.nabble.com/inbounts-calls-problems-tp2197805p2197805.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Contents of ACK in up-to-date RFC 3261
Hi,
so remove_hf("Proxy-Authorization") removes any Proxy-Authorization headers or
just the first?
What will happen if there are more than one proy auth. Header fields, will all
of them be removed? This would be a solution... but I don't want to close our
Sip proxy and only let outgoing and incoming sip calls of our domain go through.
Hmm, I tried to add an radius_proxy_authorize() before the
consume_credentials(), but as you said, I can't challenge ACKs and BYEs.
Hmm
-Original Message-
From: bog...@voice-system.ro [mailto:bog...@voice-system.ro]
Sent: Thursday, January 22, 2009 1:22 PM
To: Robert Borz
Cc: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Contents of ACK in up-to-date RFC 3261
Hi Robert,
I did read your email (even sent a reply ;))
consume_credentials() function removes only credentials that were
checked for authentication, so, in order to make it work, you have to
previously do authentication. The function works in this way because a
requests may contain credentials for multiple SIP proxies (chained
authentication), so a proxy must be careful and remove only credentials
targeting itself.
So, what you you could do is to check if the ACK has the "Proxy-Auth"
headers (with is_present_hf) and if so, use remove_hf() function to
strip it out without any check.
Regards,
Bogdan
Robert Borz wrote:
> Hi Bogdan,
>
> thanks a lot for your response!
>
> So... you're exactly saying where I run into. ;)
> Did you read my last mails with the subject "consume_credentials doesn't work
> with auth_radius module"?
>
> Maybe you can help me just by telling me what's the way people do in
> production.
>
> So... concerning my current configuration, I think I have the clue right now,
> what the problem is.
>
> If an unauthorized INVITE comes in, my SER does radius_proxy_authorize() - no
> problem here. But, to the 200 OK (Call answered), the ACK of my client also
> contains the proxy authorization credentials, which is loose-routed. And now,
> the is_present_hf("Proxy-Authorization") function returns true (which is
> correct if the UAC includes the credentials in the ACK), but
> consume_credentials() returns an error, because it doesn't know that it has
> verified (and marked) the credentials before.
>
> How to proceed in this case
>
> -Original Message-
> From: bog...@voice-system.ro [mailto:bog...@voice-system.ro]
> Sent: Thursday, January 22, 2009 8:41 AM
> To: Robert Borz
> Cc: users@lists.opensips.org
> Subject: Re: [OpenSIPS-Users] Contents of ACK in up-to-date RFC 3261
>
> Hi Robert,
>
> Robert Borz wrote:
>
>> Just had a look at RFC 3261... 269 pages... well, looks for a hard work for
>> one day... but it isn't written to understand and answer my dumb questions
>> within one or two hours. ;)
>>
>>
> indeed, the RFC3261 is like a novel :).
>
>> So, just want to know which contents in an ACK message are allowed in which
>> case...
>>
>> Especially, I'm interested in which contents in an ACK are allowed in a
>> response to a 200 OK (after INVITE)... is the Proxy-Authorization header
>> field allowed in an ACK as response to a 200 OK of an INVITE?
>>
>>
> yes, it is optional - see the RFC3261, section 20.1 , page 163 - Table 3
>
>> Maybe someone read my previous two mails, I'm a little confused right now...
>>
>> I detected different behaviour between different UACs, which is nothing
>> unusual for me (I'm just a developer, too).
>>
>> X-Lite for example includes the digest-credentials in an ACK packet in the
>> Proxy-Authorization header field, whereas the snom-softphone does not.
>> The Ekige softphone for windows also includes the Proxy-Authorization header
>> field.
>>
>> So, which behaviour is standard? It would be great to get any help from
>> you... just to spare the time reading the whole RFC... :-(
>>
>>
> well, all are correct, as the header presence in the ACK request is
> optional
>
> My understanding on the RFC (on the auth matter) is that if the INVITE
> has an "Proxy-Authorization" headers, the ACK should also contain
> one...but it is not a must, it is a recommendation. The idea is, if the
> proxy asked for auth for INVITE, it might ask for the ACK alsobut as
> you cannot challenge the ACK, the client should pre-fill the auth in ACK.
>
> Regards,
> Bogdan
>
>> But, I don’t mind reading it... ;-P
>>
>>
>> Robert.
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Needs help OpenSIPS-cp
Hi Khan, yes, in some points you are right - some things need to be changed in OCP in order to make the integration with Opensips simpler. This will be a priority for the next release of OCP. Khan Friend wrote: > I am in process of installation of OCP, I read the installation > instructions. Im running OpenSIPS 1.4.2. Installation instruction does > not say anything about changing SQL or .sh file. The sample files > refer to database OpenSIPS_1_4, I assumed that i need to rename them > to my db which is opensips thus I created cdr table in my opensips db. Change in all places the DB name to opensips - the cdr table must be in the same db as opensips. > > The table acc does not have caller_id, callee_id, destination, and > some other fields. I added those columns in opensips database table acc. simply remove those fields from the acc, cdr and cdr procedure - you do not need them. (this will be fixed) > > I was wondering am i doing right so far? Why installation instructions > doesn't talk about it? OR Do I have to create new database with the > name opensips_1_4? no need to create a new one - use the opensips DB. Regards, Bogdan > > Please help. > > Khan > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Contents of ACK in up-to-date RFC 3261
Hi Robert,
I did read your email (even sent a reply ;))
consume_credentials() function removes only credentials that were
checked for authentication, so, in order to make it work, you have to
previously do authentication. The function works in this way because a
requests may contain credentials for multiple SIP proxies (chained
authentication), so a proxy must be careful and remove only credentials
targeting itself.
So, what you you could do is to check if the ACK has the "Proxy-Auth"
headers (with is_present_hf) and if so, use remove_hf() function to
strip it out without any check.
Regards,
Bogdan
Robert Borz wrote:
> Hi Bogdan,
>
> thanks a lot for your response!
>
> So... you're exactly saying where I run into. ;)
> Did you read my last mails with the subject "consume_credentials doesn't work
> with auth_radius module"?
>
> Maybe you can help me just by telling me what's the way people do in
> production.
>
> So... concerning my current configuration, I think I have the clue right now,
> what the problem is.
>
> If an unauthorized INVITE comes in, my SER does radius_proxy_authorize() - no
> problem here. But, to the 200 OK (Call answered), the ACK of my client also
> contains the proxy authorization credentials, which is loose-routed. And now,
> the is_present_hf("Proxy-Authorization") function returns true (which is
> correct if the UAC includes the credentials in the ACK), but
> consume_credentials() returns an error, because it doesn't know that it has
> verified (and marked) the credentials before.
>
> How to proceed in this case
>
> -Original Message-
> From: bog...@voice-system.ro [mailto:bog...@voice-system.ro]
> Sent: Thursday, January 22, 2009 8:41 AM
> To: Robert Borz
> Cc: users@lists.opensips.org
> Subject: Re: [OpenSIPS-Users] Contents of ACK in up-to-date RFC 3261
>
> Hi Robert,
>
> Robert Borz wrote:
>
>> Just had a look at RFC 3261... 269 pages... well, looks for a hard work for
>> one day... but it isn't written to understand and answer my dumb questions
>> within one or two hours. ;)
>>
>>
> indeed, the RFC3261 is like a novel :).
>
>> So, just want to know which contents in an ACK message are allowed in which
>> case...
>>
>> Especially, I'm interested in which contents in an ACK are allowed in a
>> response to a 200 OK (after INVITE)... is the Proxy-Authorization header
>> field allowed in an ACK as response to a 200 OK of an INVITE?
>>
>>
> yes, it is optional - see the RFC3261, section 20.1 , page 163 - Table 3
>
>> Maybe someone read my previous two mails, I'm a little confused right now...
>>
>> I detected different behaviour between different UACs, which is nothing
>> unusual for me (I'm just a developer, too).
>>
>> X-Lite for example includes the digest-credentials in an ACK packet in the
>> Proxy-Authorization header field, whereas the snom-softphone does not.
>> The Ekige softphone for windows also includes the Proxy-Authorization header
>> field.
>>
>> So, which behaviour is standard? It would be great to get any help from
>> you... just to spare the time reading the whole RFC... :-(
>>
>>
> well, all are correct, as the header presence in the ACK request is
> optional
>
> My understanding on the RFC (on the auth matter) is that if the INVITE
> has an "Proxy-Authorization" headers, the ACK should also contain
> one...but it is not a must, it is a recommendation. The idea is, if the
> proxy asked for auth for INVITE, it might ask for the ACK alsobut as
> you cannot challenge the ACK, the client should pre-fill the auth in ACK.
>
> Regards,
> Bogdan
>
>> But, I don’t mind reading it... ;-P
>>
>>
>> Robert.
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem with new version of Dynamic Routing
Hi Matteo,
Please update from SVN - I did so more logging. Also be sure you use
also the latest version of TM (update the whole SVN tree to the latest
trunk version).
Regards,
Bogdan
mmarzu...@interfree.it wrote:
> Hi.
> I deleted append_branch by the script, but the failure route does not work.
> In the syslog there is:
>
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]: Method is an
> INVITE
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]: Call to PSTN
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:db_new_result: allocate 28 bytes for result set at 0x81b2958
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:db_allocate_columns: allocate 4 bytes for result names at 0x81b2400
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:db_allocate_columns: allocate 4 bytes for result types at 0x81b2980
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:db_mysql:db_mysql_get_columns: allocate 8 bytes for RES_NAMES[0] at
> 0x81b2990
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x81b2990)[0]=[groupid]
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:db_mysql:db_mysql_convert_rows: allocate 8 bytes for rows at 0x81b29a0
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:db_mysql:db_mysql_convert_row: allocate 20 bytes for row values at
> 0x81b29b0
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:db_mysql:db_mysql_str2val: converting INT [0]
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:db_free_columns: freeing 1 columns
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:db_free_columns: freeing RES_NAMES[0] at 0x81b2990
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:db_free_columns: freeing result names at 0x81b2400
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:db_free_columns: freeing result types at 0x81b2980
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:db_free_rows: freeing 1 rows
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:db_free_row: freeing row values at 0x81b29b0
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:db_free_rows: freeing rows at 0x81b29a0
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:db_free_result: freeing result set at 0x81b2958
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:drouting:do_routing: using dr group 0
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:drouting:internal_check_rt: found rgid 0 (rule list 0xb5b1af68)
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:drouting:ac_tm_fill: ---> fill = Thu Jan 22 11:52:45 2009
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:drouting:ac_tm_fill: ---> fill = Thu Jan 22 11:52:45 2009
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]: messagge outbound
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:parse_headers: flags=
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:get_hdr_field: content_length=285
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:core:get_hdr_field: found end of header
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:drouting:do_routing: adding gw [1] as avp "sip:2223...@10.10.45.102"
> Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
> DBG:drouting:do_routing: setting the gw [0] as ruri "sip:2223...@10.10.45.78"
>
>
> The proxy tries to deliver the call to the first gateway that is down
> specially to test the failover
>
>
> Jan 22 11:53:15 opensips-lab /usr/local/sbin/opensips[3647]: failure route 2
> Jan 22 11:53:15 opensips-lab /usr/local/sbin/opensips[3647]:
> DBG:drouting:use_next_gw: setting new RURI <>
> Jan 22 11:53:15 opensips-lab /usr/local/sbin/opensips[3647]: selected new
> gateway
> Jan 22 11:53:15 opensips-lab /usr/local/sbin/opensips[3647]:
> ERROR:tm:t_forward_nonack: no branch for forwarding
> Jan 22 11:53:15 opensips-lab /usr/local/sbin/opensips[3647]:
> ERROR:tm:w_t_relay: t_forward_nonack failed
>
> The URI of the second gateway is not set and then I get a 408 messagge.
>
> What's wrong?
>
> route {
>
> *
> ***
>
> if (is_method("INVITE")) {
> xlog("L_INFO", "Method is an INVITE\n");
> #setflag(4);
> setflag(1); # do accounting
> if($rU=~"3.*") {
> xlog("L_
Re: [OpenSIPS-Users] Users Digest, Vol 6, Issue 87
Hi, Not sure if you figured this out, but this can only happen when xcap-diff publishing is enabled. So, unless you require this functionality disable it with [OpenSER] enable_publish_xcapdiff = no > I am having the same issue with Kamailio. Did you ever figure out what this > was happening? > > > > > mika.saari wrote: > >> Hi, >> >> Both OpenXCAP 1.0.6 and 1.0.7_Preview gives error below when subscribing >> or unsubsribing the presence status. What might be wrong ? OS = Debian >> Lenny AMD64. >> >> Thank you very much, >> -Mika >> >> Unhandled error in Deferred: >> Traceback (most recent call last): >> File "/usr/lib/python2.5/site-packages/twisted/web/xmlrpc.py", line 287, >> in handleResponse >> self.factory.parseResponse(contents) >> File "/usr/lib/python2.5/site-packages/twisted/web/xmlrpc.py", line 318, >> in parseResponse >> deferred.errback(failure.Failure()) >> File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line >> 269, in errback >> self._startRunCallbacks(fail) >> File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line >> 312, in _startRunCallbacks >> self._runCallbacks() >> --- --- >> File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line >> 328, in _runCallbacks >> self.result = callback(self.result, *args, **kw) >> File "/usr/lib/python2.5/site-packages/xcap/interfaces/openser.py", line >> 92, in repeat_publish_if_wrong_etag >> if x.value[0] == '418' and etag != '.': >> exceptions.IndexError: tuple index out of range >> >> >> >> ___ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem with new version of Dynamic Routing
Hi.
I deleted append_branch by the script, but the failure route does not work.
In the syslog there is:
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]: Method is an INVITE
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]: Call to PSTN
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:db_new_result: allocate 28 bytes for result set at 0x81b2958
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:db_allocate_columns: allocate 4 bytes for result names at 0x81b2400
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:db_allocate_columns: allocate 4 bytes for result types at 0x81b2980
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:db_mysql:db_mysql_get_columns: allocate 8 bytes for RES_NAMES[0] at
0x81b2990
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x81b2990)[0]=[groupid]
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:db_mysql:db_mysql_convert_rows: allocate 8 bytes for rows at 0x81b29a0
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:db_mysql:db_mysql_convert_row: allocate 20 bytes for row values at 0x81b29b0
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:db_mysql:db_mysql_str2val: converting INT [0]
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:db_free_columns: freeing 1 columns
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:db_free_columns: freeing RES_NAMES[0] at 0x81b2990
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:db_free_columns: freeing result names at 0x81b2400
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:db_free_columns: freeing result types at 0x81b2980
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:db_free_rows: freeing 1 rows
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:db_free_row: freeing row values at 0x81b29b0
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:db_free_rows: freeing rows at 0x81b29a0
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:db_free_result: freeing result set at 0x81b2958
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:drouting:do_routing: using dr group 0
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:drouting:internal_check_rt: found rgid 0 (rule list 0xb5b1af68)
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:drouting:ac_tm_fill: ---> fill = Thu Jan 22 11:52:45 2009
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:drouting:ac_tm_fill: ---> fill = Thu Jan 22 11:52:45 2009
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]: messagge outbound
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:parse_headers: flags=
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:get_hdr_field: content_length=285
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:core:get_hdr_field: found end of header
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:drouting:do_routing: adding gw [1] as avp "sip:2223...@10.10.45.102"
Jan 22 11:52:45 opensips-lab /usr/local/sbin/opensips[3645]:
DBG:drouting:do_routing: setting the gw [0] as ruri "sip:2223...@10.10.45.78"
The proxy tries to deliver the call to the first gateway that is down specially
to test the failover
Jan 22 11:53:15 opensips-lab /usr/local/sbin/opensips[3647]: failure route 2
Jan 22 11:53:15 opensips-lab /usr/local/sbin/opensips[3647]:
DBG:drouting:use_next_gw: setting new RURI <>
Jan 22 11:53:15 opensips-lab /usr/local/sbin/opensips[3647]: selected new
gateway
Jan 22 11:53:15 opensips-lab /usr/local/sbin/opensips[3647]:
ERROR:tm:t_forward_nonack: no branch for forwarding
Jan 22 11:53:15 opensips-lab /usr/local/sbin/opensips[3647]:
ERROR:tm:w_t_relay: t_forward_nonack failed
The URI of the second gateway is not set and then I get a 408 messagge.
What's wrong?
route {
*
***
if (is_method("INVITE")) {
xlog("L_INFO", "Method is an INVITE\n");
#setflag(4);
setflag(1); # do accounting
if($rU=~"3.*") {
xlog("L_INFO", "Call to PSTN\n");
do_routing();
t_relay();
t_on_failure("2");
exit;
}
}
*
***
}
route [2] {
#route triggered by DR
xlog("L_INFO","messagge outbound\n");
append_hf("P-hint: outbound\r\n");
exit;
}
failure_route[2] {
xlog("L_
Re: [OpenSIPS-Users] Contents of ACK in up-to-date RFC 3261
Hi Bogdan,
thanks a lot for your response!
So... you're exactly saying where I run into. ;)
Did you read my last mails with the subject "consume_credentials doesn't work
with auth_radius module"?
Maybe you can help me just by telling me what's the way people do in production.
So... concerning my current configuration, I think I have the clue right now,
what the problem is.
If an unauthorized INVITE comes in, my SER does radius_proxy_authorize() - no
problem here. But, to the 200 OK (Call answered), the ACK of my client also
contains the proxy authorization credentials, which is loose-routed. And now,
the is_present_hf("Proxy-Authorization") function returns true (which is
correct if the UAC includes the credentials in the ACK), but
consume_credentials() returns an error, because it doesn't know that it has
verified (and marked) the credentials before.
How to proceed in this case
-Original Message-
From: bog...@voice-system.ro [mailto:bog...@voice-system.ro]
Sent: Thursday, January 22, 2009 8:41 AM
To: Robert Borz
Cc: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Contents of ACK in up-to-date RFC 3261
Hi Robert,
Robert Borz wrote:
> Just had a look at RFC 3261... 269 pages... well, looks for a hard work for
> one day... but it isn't written to understand and answer my dumb questions
> within one or two hours. ;)
>
indeed, the RFC3261 is like a novel :).
> So, just want to know which contents in an ACK message are allowed in which
> case...
>
> Especially, I'm interested in which contents in an ACK are allowed in a
> response to a 200 OK (after INVITE)... is the Proxy-Authorization header
> field allowed in an ACK as response to a 200 OK of an INVITE?
>
yes, it is optional - see the RFC3261, section 20.1 , page 163 - Table 3
> Maybe someone read my previous two mails, I'm a little confused right now...
>
> I detected different behaviour between different UACs, which is nothing
> unusual for me (I'm just a developer, too).
>
> X-Lite for example includes the digest-credentials in an ACK packet in the
> Proxy-Authorization header field, whereas the snom-softphone does not.
> The Ekige softphone for windows also includes the Proxy-Authorization header
> field.
>
> So, which behaviour is standard? It would be great to get any help from
> you... just to spare the time reading the whole RFC... :-(
>
well, all are correct, as the header presence in the ACK request is
optional
My understanding on the RFC (on the auth matter) is that if the INVITE
has an "Proxy-Authorization" headers, the ACK should also contain
one...but it is not a must, it is a recommendation. The idea is, if the
proxy asked for auth for INVITE, it might ask for the ACK alsobut as
you cannot challenge the ACK, the client should pre-fill the auth in ACK.
Regards,
Bogdan
> But, I don’t mind reading it... ;-P
>
>
> Robert.
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] New User - Trying to use variables instead of IP no's
Hi Matti, Matti Zemack wrote: > > Hi all, > > I’m new to Opensips and love the speed of the code. Even in the VmWare > dev server I’m running on my (ancient) desktop machine! > > As a first attempt at my new job I thought I could try and rewrite the > config-scripts used at my company so that one script easily could be > used in both dev and all the different Live environments. > > Basically I could change a variable early in the opensips.cfg, and > this would assign the correct IP’s for me to be used later in the config. > > But I suspect I’m using Opensips variables in the wrong way… > > Example of original code: > > rewritehostport(“10.0.1.100:5060”); > > Which I try changing to: > > $var(GateWay_5060)=”10.0.1.100:5060”; > > rewritehostport(“$var(GateWay_5060)”); > Try: $var(GateWay_5060)=”10.0.1.100:5060”; $rd = $var(GateWay_5060); or $rd = 10.0.1.100:5060” Regards, Bogdan > (This gives me runtime error: ERROR:tm:uri2proxy: bad host name in URI > ) > > Actually also tried rewritehostport($var(GateWay_5060)); which also > gives error: String expected… > > So basically, I suppose I’m asking; > > How can I cast variables in Opensips? Or should I do this some other, > smarter, way? > > Thanks in advance, > > Matti Zemack > > Stockholm > > Sweden > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] New User - Trying to use variables instead of IP no's
2009/1/22 Matti Zemack :
> As a first attempt at my new job I thought I could try and rewrite the
> config-scripts used at my company so that one script easily could be used in
> both dev and all the different Live environments.
>
> Basically I could change a variable early in the opensips.cfg, and this
> would assign the correct IP's for me to be used later in the config.
>
>
> But I suspect I'm using Opensips variables in the wrong way…
>
> Example of original code:
>
> rewritehostport("10.0.1.100:5060");
>
> Which I try changing to:
>
> $var(GateWay_5060)="10.0.1.100:5060";
>
> rewritehostport("$var(GateWay_5060)");
>
> (This gives me runtime error: ERROR:tm:uri2proxy: bad host name in URI
> )
>
> Actually also tried rewritehostport($var(GateWay_5060)); which also gives
> error: String expected…
>
>
>
> So basically, I suppose I'm asking;
>
> How can I cast variables in Opensips? Or should I do this some other,
> smarter, way?
Some functions (as "rewritehostport") don't allow pseudo-variables as
parameters.
I stringly recommend you to use M4 to compile your opensips.cfg file:
file /etc/opensips/opensips.cfg.m4:
-
debug=3
log_stderror=no
log_facility=LOG_LOCAL7
fork=yes
...
listen=MY_IP:MY_PORT
...
rewritehost("MEDIA_SERVER_IP:MEDIA_SERVER_PORT");
...
-
file /etc/opensips/defines.m4 (at your home):
-
divert(-1)
define(`MY_IP', `192.168.10.23')
define(`MY_PORT', `5060')
define(`MEDIA_SERVER_IP', `192.168.10.23')
define(`MEDIA_SERVER_PORT', `5065')
divert(0)dnl
-
file /etc/opensips/defines.m4 (at your office):
-
divert(-1)
define(`MY_IP', `123.123.123.123')
define(`MY_PORT', `5060')
define(`MEDIA_SERVER_IP', `22.22.22.22')
define(`MEDIA_SERVER_PORT', `5065')
divert(0)dnl
-
Create a bash script:
/usr/local/bin/op-restart.sh:
--
#!/bin/bash
DIR="/etc/opensips"
m4 $DIR/defines.m4 $DIR/opensips.cfg.m4 > $DIR/opensips.cfg
/etc/init.d/opensips restart
--
So you just must change the /etc/opensips/opensips.cfg.m4 file and the
defines.m4 (this last file will be different depending on your
location).
--
Iñaki Baz Castillo
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] New User - Trying to use variables instead of IP no's
Hi all,
I'm new to Opensips and love the speed of the code. Even in the VmWare
dev server I'm running on my (ancient) desktop machine!
As a first attempt at my new job I thought I could try and rewrite the
config-scripts used at my company so that one script easily could be
used in both dev and all the different Live environments.
Basically I could change a variable early in the opensips.cfg, and this
would assign the correct IP's for me to be used later in the config.
But I suspect I'm using Opensips variables in the wrong way...
Example of original code:
rewritehostport("10.0.1.100:5060");
Which I try changing to:
$var(GateWay_5060)="10.0.1.100:5060";
rewritehostport("$var(GateWay_5060)");
(This gives me runtime error: ERROR:tm:uri2proxy: bad host name in URI
)
Actually also tried rewritehostport($var(GateWay_5060)); which also
gives error: String expected...
So basically, I suppose I'm asking;
How can I cast variables in Opensips? Or should I do this some other,
smarter, way?
Thanks in advance,
Matti Zemack
Stockholm
Sweden
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Failed builing rev 5182
2009/1/21 Dan Pascu : > On Tuesday 20 January 2009, Joan wrote: >> I am having problems when building opensips 1.5 rev 5182 on a ubuntu >> 8.04 On the 2009-01-15 build there was no problem on the same system, >> something might have been broken afterwards. >> I attach the build log > > You did a svn update in a tree which was modified by a debian build, > without first cleaning the debian build. You should know better. > Compilation still was broken when I did the build from from a fresh checkout and of course I also tried removing the files altered for me after doing an "svn status" and watching wich ones they where. Oh, and isn't the directory cleaned at the first step when you're doing a make deb? > -- > Dan > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] different between nathelper and nat_traversal
2009/1/22 Pezhman Lali : > Dear, > I find nathelper and nat_traversal modules very similar. > I think the only different between them is using rtpproxy. > is any more different? nathelper, until now, solves the NAT signalling problem. this means: detects NAT based on request/response headers and real source IP, and also "fixes" it by replacing privates adresses by the received public address (in Contact for example). nathelper communicates with RtpProxy so it can also fixes the privates addresses in the SDP. And also, it mantains the keepalive of natted registered users. But nathelper has some limitations: it cannot keepalive connection from non registered users, or SUBSCRIBE dialogs. It also require that users behind NAT use their outbound proxy as registrar, is not, keepalive will not work. nat_traversal is a more ellegant and powerful solution but just for the signalling. It doesn't control RtpProxy, but it has more features missing in nathelper. But please, read the *full* documentation of nat_traversal module, all the features are well explained. AFAIK, in a future nathelper will loose signalling related funcionts and will become just a "driver" to manage RtpProxy and modify SDP's. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] different between nathelper and nat_traversal
Dear,I find nathelper and nat_traversal modules very similar. I think the only different between them is using rtpproxy. is any more different? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
