Re: [OpenSIPS-Users] groupID avp with do_routing
Hi Richard, Yes, that is true (about the types) - I just added a clear warning in the documentation of the drouting module :) Thanks and regards, Bogdan On 04/12/2011 06:46 PM, Richard Revels wrote: Hope this saves someone time at some point. The type of value stored in the groupID avp (if used) when calling do_routing() must be an int. There is no attempt to convert in the function. I store everything in usr_preferences as a string and then use transforms where needed in the config script. Took me a day to realize I needed one for this. Richard ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS eBootcamp - 2nd of May 2011 OpenSIPS solutions and know-how ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem with Diversion when added in failure route and RURI uses DNS SRV
Hi Dave, Interesting pointit is undocumented feature of how the dns based failover is implemented. It is actually doing serial forking, so creating a new branch - the changes in failure route are per branch, so what you change in failure route (via append_hf) is discarded for the next branch created by DNS failover... Never thought on that :DI say it is bug, so please open a bug report on tracker. Thanks and regards, Bogdan On 04/12/2011 01:17 AM, Dave Singer wrote: I have a server running 1.6.3. In failure route I add a Diversion and the RURI is a DNS SRV record and sometimes one of the servers times out and opensips auto tries the second server from the SRV records but without the diversion header in the new message Is this proper/expected behavior or a bug? I would think for SRV it would only change the destination IP. Especially where you don't have an opportunity to make any fixes to the original message (what it was just before any branches). Dave ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS eBootcamp - 2nd of May 2011 OpenSIPS solutions and know-how ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] uac_replace_from auto mode with to_tag ignores display name
Hi Guys, actually it is not a configuration problem at all - the UAC module does not restore the DISPLAY part of FROM/TO, but only the URI part (in sequential requests). Regards, Bogdan On 04/12/2011 05:57 PM, Jeff Pyle wrote: Razvan, On the initial INVITE the first parameter is not set to . I run the function as follows: uac_replace_from($var(id_namereplace), sip:$avp(s:id_num)@$Ri); On the initial INVITE, both the display name and the URI are updated correctly, that is, with the values put into the function. The problem happens in loose_route when the URI is updated but the display name is not. To get around the problem of the original display name leaking through loose route, I have added the following functions to neutralize it completely. No display name on subsequent requests is better than the wrong name: if (is_direction(downstream)) uac_replace_from(,); if (is_direction(upstream)) uac_replace_to(,); This does effectively remove the display name without touching the URI. But shouldn't the display name be updated automatically (in auto mode) just as the URI is? - Jeff From: Razvan Crainea razvancrai...@opensips.org mailto:razvancrai...@opensips.org Reply-To: OpenSIPS users mailling list users@lists.opensips.org mailto:users@lists.opensips.org Date: Tue, 12 Apr 2011 03:42:44 -0400 To: users@lists.opensips.org mailto:users@lists.opensips.org users@lists.opensips.org mailto:users@lists.opensips.org Subject: Re: [OpenSIPS-Users] uac_replace_from auto mode with to_tag ignores display name Hello, Jeff, Please make sure that the first parameter is not set to . As you can see here[1], if the first parameter of uac_replace_from method is , it removes the Display name. Regards, Razvan [1] http://www.opensips.org/html/docs/modules/devel/uac.html#id292701 On 04/11/2011 07:03 PM, Jeff Pyle wrote: Hello, I run uac_replace_from (auto mode) in a branch_route. Subsequents requests for the same dialog (with to_tag, through loose_route) have the From URI updated correctly, but the display name isn't. Is this a misconfiguration on my part, by design, or a bug? - Jeff ___ Users mailing list Users@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS eBootcamp - 2nd of May 2011 OpenSIPS solutions and know-how ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Load Balancer Failing on search_body - Looks okay?
Hi Alan,
So if I understand correctly, the load_balance() function fails and you
send the 503 from the script ? if so, do you get anything relevant in
logs (about the failure)? try to set debug=6 to get more info (not
recommended if a production system).
Regards,
Bogdan
On 04/11/2011 05:22 AM, Alan Frisch wrote:
For some odd reason my OpenSIPs load_balancer module seems to fail
with certain clients. Works fine with Asterisk and some other
servers, but have had the occasional client get a 503 returned to it.
In this case, it's a SIP application for an Android phone... I get a
bug - cannot find request resource in dst in my logs.
Relevant OpenSIPs code is below. I'm searching for PCMU and PCMA, for
some reason the tutorial uses search_body with G711 but you never
see G711 in SDP, AFAIK.
if (!search_body([Pp][Cc][Mm][Uu]) !search_body([Pp][Cc][Mm][Aa])) {
if (!load_balance(1,transc;pstn,1))
{
t_reply(503, Circuit Unavailable - TP);
exit;
}
} else {
if (!load_balance(1,pstn,1))
{
t_reply(503, Circuit Unavailable - P);
exit;
}
}
}
The incoming SDP is:
v=0
o=- 3511475179 3511475179 IN IP4 99.28.22.29
s=pjmedia
c=IN IP4 99.228.252.229
t=0 0
a=X-nat:8
m=audio 4000 RTP/AVP 0 8 18 101
a=rtcp:4001 IN IP4 99.28.22.29
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
My LB list looks like this:
Destination:: sip:x.x.x.10:5060 id=1 group=1 enabled=yes auto-re=on
Resource:: pstn max=30 load=5
Resource:: transc max=30 load=1
Destination:: sip:x.x.x.11:5060 id=10 group=1 enabled=yes auto-re=on
Resource:: pstn max=40 load=7
Resource:: transc max=40 load=2
The destination machines in the LB list are not loaded down but the
call falls down to the second part (since no transcoding is needed)
but then fails totally. Is there a way to find out what resource it
is trying to look for?
Any help is appreciated!
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and know-how
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] function with 6 parameters
Hello, Bogdan,
The problem is that the function you are using to fetch the values of
the pseudo variables (fixup_get_svalue) uses static buffers to store the
string values. These buffers are only 5 an they are used circularly.
That's why the first value is the same with the last one.
The best solution is to make sure you don't use more than 5 buffers
concurrently, preferably process the value right after fetching it (in
your example print the value right after getting it). Another solution
is to use the pv_printf function where you can specify your buffer. As
a last resort you can increase the buffers number in pvar.c (search
PV_PRINT_BUF_NO definition).
Regards,
Razvan
On 04/13/2011 01:58 PM, rad bogdan wrote:
Hi Razvan,
I've applied the patch you gave me.
This is the output:
INFO:core:do_action: called test6(0x81b1398, 0x81b144c, 0x81b14b4,
0x81b151c, 0x81b1584, 0x81b15ec)
INFO:test:test6: arg1: [789]
INFO:test:test6: arg2: [222]
INFO:test:test6: arg3: [333]
INFO:test:test6: arg4: [123]
INFO:test:test6: arg5: [456]
INFO:test:test6: arg6: [789]
INFO:core:fix_actions: fixed test6[1] 0x81b1398
INFO:core:fix_actions: fixed test6[2] 0x81b144c
INFO:core:fix_actions: fixed test6[3] 0x81b14b4
INFO:core:fix_actions: fixed test6[4] 0x81b151c
INFO:core:fix_actions: fixed test6[5] 0x81b1584
INFO:core:fix_actions: fixed test6[6] 0x81b15ec
This is the code from opensips.cfg:
$var(var1) = 111;
$var(var2) = 222;
$var(var3) = 333;
$avp(s:avp1) = 123;
$avp(s:avp2) = 456;
$avp(s:avp3) = 789;
test6($var(var1), $var(var2), $var(var3), $avp(s:avp1),
$avp(s:avp2), $avp(s:avp3));
Attached is the module.
Thanks,
Bogdan
--- On *Mon, 4/11/11, Razvan Crainea /razvancrai...@opensips.org/*
wrote:
From: Razvan Crainea razvancrai...@opensips.org
Subject: Re: [OpenSIPS-Users] function with 6 parameters
To: users@lists.opensips.org
Date: Monday, April 11, 2011, 1:45 PM
Hello Bogdan,
I implemented a similar test function that takes 6 parameters.
All values seems to be in the correct order in both fixup function
and triggered function.
I attached a small patch that prints the value of the parameters
right after the fixup function and then again before the function
is called.
Please apply this patch and then check if the parameters values
and order match between the fixup and triggered function?
Regards,
Razvan
On 04/06/2011 05:51 PM, rad bogdan wrote:
Hi Bogdan,
The inversion is only in the triggered function.
The arguments are passed correctly from left to right to the
fixup function.
The triggered function is:
test_function(struct sip_msg *msg, char *arg1, char *arg2, char*
arg3, char* arg4, char* arg5, char* arg6)
{
str arg1_s = {NULL, 0};
if(arg1 == NULL || fixup_get_svalue(msg, (gparam_p)arg1,
arg1_s) != 0)
{
LM_ERR(Invalid arg1 argument\n);
return -1;
}
.
}
arg1_s.s has the value of arg6_s.s while arg6_s.s has the correct
value.
Thanks,
Bogdan
--- On *Wed, 4/6/11, Bogdan-Andrei Iancu /bog...@opensips.org
/mc/compose?to=bog...@opensips.org/* wrote:
From: Bogdan-Andrei Iancu bog...@opensips.org
/mc/compose?to=bog...@opensips.org
Subject: Re: [OpenSIPS-Users] function with 6 parameters
To: OpenSIPS users mailling list users@lists.opensips.org
/mc/compose?to=users@lists.opensips.org
Cc: rad bogdan bogdan_rad2...@yahoo.com
/mc/compose?to=bogdan_rad2...@yahoo.com
Date: Wednesday, April 6, 2011, 5:15 PM
Hi Bogdan,
This inversion is visible in the fixup function or is the
triggered function ?
Regards,
Bogdan
On 04/06/2011 02:44 PM, rad bogdan wrote:
Hi everyone,
I implemented an OpenSIPS custom module that communicates
with an external application. From the routing script I call
a function with 6 parameters:
test_function('$fU', '$tU', '$ci', '$avp(s:name1)',
'$avp(s:name2)', '$var(name3)')
The problem is that when the corresponding function is
called in C, the first parameter gets the value of the last one.
This doesn't happen when the function is made to take 5
parameters.
The fixup function that I use is this:
static int pvn_fixup_spve_spve_6(void** param, int param_no)
{
if (!(param_no = 1 param_no = 6))
{
LM_ERR(invalid parameter number %d\n, param_no);
return E_UNSPEC;
}
return fixup_spve(param);
}
Is there something wrong with it or the problem is elsewhere ?
Thanks,
Bogdan
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Unable to call using Opensips via TLS
HI ,
I am using opensips with TLS enabled.Iam trying to establish a call via
TLS,both the clients are able to register,but when a message/call is sent I
get the following error
SIP/2.0 200 OK
Via: SIP/2.0/TLS 10.1.1.102:1268
;rport=1268;branch=z9hG4bKPj021189d9cdb2430998ee8f0d36cc173d
From: sip:2000@20.1.1.2;tag=3f23894087f04dc599171a376667a716
To: sip:2000@20.1.1.2;tag=e4628f3555f473813fff196cef35ce47.52fc
Call-ID: fc6971a239f14ed6942339b96e5e6985
CSeq: 47334 REGISTER
Contact: sip:2000@10.1.1.102:4000;transport=TLS;expires=300
Server: OpenSIPS (1.6.4-2-tls (i386/linux))
Content-Length: 0
Apr 17 08:32:38 [29262] DBG:core:destroy_avp_list: destroying list (nil)
Apr 17 08:32:38 [29262] DBG:core:receive_msg: cleaning up
Apr 17 08:32:44 [29262] DBG:core:tcp_receive_timeout: 0xb610c728 expired
(31, 32) lt=0
Apr 17 08:32:44 [29262] DBG:core:io_watch_del: io_watch_del (0x81a2ea0, 13,
-1, 0x10) fd_no=2 called
Apr 17 08:32:44 [29262] DBG:core:release_tcpconn: releasing con 0xb610c728,
state 0, fd=13, id=2
Apr 17 08:32:44 [29262] DBG:core:release_tcpconn: extra_data 0xb6109548
Apr 17 08:32:44 [29271] DBG:core:handle_tcp_child: reader response=
b610c728, 0 from 0
Apr 17 08:32:44 [29271] DBG:core:io_watch_add: io_watch_add(0x81a2d40, 19,
2, 0xb610c728), fd_no=13
Apr 17 08:32:44 [29271] DBG:core:handle_tcp_child: cmd CONN_RELEASE
0xb610c728 refcnt= 0
Apr 17 08:32:46 [29271] DBG:core:handle_tcpconn_ev: data available on
0xb60e26c4 18
Apr 17 08:32:46 [29271] DBG:core:io_watch_del: io_watch_del (0x81a2d40, 18,
-1, 0x0) fd_no=14 called
Apr 17 08:32:46 [29271] DBG:core:send2child: to tcp child 0 0(29262),
0xb60e26c4
Apr 17 08:32:46 [29262] DBG:core:handle_io: received n=4 con=0xb60e26c4,
fd=13
Apr 17 08:32:46 [29262] DBG:core:io_watch_add: io_watch_add(0x81a2ea0, 13,
2, 0xb60e26c4), fd_no=1
Apr 17 08:32:46 [29262] DBG:core:tls_update_fd: New fd is 13
Apr 17 08:32:46 [29262] DBG:core:_tls_read: 4 bytes read
Apr 17 08:32:46 [29262] DBG:core:tcp_read_req: content-length= 0
Apr 17 08:32:46 [29262] DBG:core:tcp_send: tcp connection found
(0xb60e26c4), acquiring fd
Apr 17 08:32:46 [29262] DBG:core:tcp_send: c= 0xb60e26c4, n=8
Apr 17 08:32:46 [29271] DBG:core:handle_ser_child: read response= b60e26c4,
1, fd -1 from 4 (29262)
Apr 17 08:32:46 [29262] DBG:core:tcp_send: after receive_fd: c= 0xb60e26c4
n=4 fd=14
Apr 17 08:32:46 [29262] DBG:core:tcp_send: sending...
Apr 17 08:32:46 [29262] DBG:core:tls_update_fd: New fd is 14
Apr 17 08:32:46 [29262] DBG:core:tls_write: write was successful (2 bytes)
Apr 17 08:32:46 [29262] DBG:core:tcp_send: after write: c= 0xb60e26c4 n=2
fd=14
Apr 17 08:32:46 [29262] DBG:core:tcp_send: buf=
Apr 17 08:32:52 [29262] DBG:core:tls_update_fd: New fd is 13
Apr 17 08:32:52 [29262] DBG:core:_tls_read: 543 bytes read
Apr 17 08:32:52 [29262] DBG:core:tcp_read_req: content-length= 2
Apr 17 08:32:52 [29262] DBG:core:parse_msg: SIP Request:
Apr 17 08:32:52 [29262] DBG:core:parse_msg: method: MESSAGE
Apr 17 08:32:52 [29262] DBG:core:parse_msg: uri: sip:1000@20.1.1.2
Apr 17 08:32:52 [29262] DBG:core:parse_msg: version: SIP/2.0
Apr 17 08:32:52 [29262] DBG:core:parse_headers: flags=2
Apr 17 08:32:52 [29262] DBG:core:parse_via_param: found param type 235,
rport = n/a; state=6
Apr 17 08:32:52 [29262] DBG:core:parse_via_param: found param type 232,
branch = z9hG4bKPja09ec884d91f4b0faea630f9fbc156bf; state=16
Apr 17 08:32:52 [29262] DBG:core:parse_via: end of header reached, state=5
Apr 17 08:32:52 [29262] DBG:core:parse_headers: via found, flags=2
Apr 17 08:32:52 [29262] DBG:core:parse_headers: this is the first via
Apr 17 08:32:52 [29262] DBG:core:receive_msg: After parse_msg...
Apr 17 08:32:52 [29262] DBG:core:receive_msg: preparing to run routing
scripts...
Apr 17 08:32:52 [29262] DBG:core:parse_headers: flags=100
Apr 17 08:32:52 [29262] DBG:maxfwd:is_maxfwd_present: value = 70
Apr 17 08:32:52 [29262] DBG:core:parse_headers: flags=8
Apr 17 08:32:52 [29262] DBG:core:parse_to: end of header reached, state=10
Apr 17 08:32:52 [29262] DBG:core:parse_to: display={}, ruri={
sip:1000@20.1.1.2}
Apr 17 08:32:52 [29262] DBG:core:get_hdr_field: To [21]; uri=[
sip:1000@20.1.1.2]
Apr 17 08:32:52 [29262] DBG:core:get_hdr_field: to body [sip:1000@20.1.1.2
]
Apr 17 08:32:52 [29262] DBG:uri:has_totag: no totag
Apr 17 08:32:52 [29262] DBG:core:parse_headers: flags=78
Apr 17 08:32:52 [29262] DBG:core:get_hdr_field: cseq CSeq: 15905
MESSAGE
Apr 17 08:32:52 [29262] DBG:tm:t_lookup_request: start searching:
hash=15450, isACK=0
Apr 17 08:32:52 [29262] DBG:tm:matching_3261: RFC3261 transaction matching
failed
Apr 17 08:32:52 [29262] DBG:tm:t_lookup_request: no transaction found
Apr 17 08:32:52 [29262] DBG:core:parse_to_param:
tag=d5b6699b53424475b7588a272b462a3f
Apr 17 08:32:52 [29262] DBG:core:parse_to: end of header reached, state=29
Apr 17 08:32:52 [29262] DBG:core:parse_to: display={}, ruri={
sip:1000@20.1.1.2}
Apr 17 08:32:52 [29262] DBG:core:grep_sock_info: checking if host==us: 8==8
[20.1.1.2] == [20.1.1.2]
Apr 17
Re: [OpenSIPS-Users] uac_replace_from auto mode with to_tag ignores display name
Bogdan, That's what I wanted to know. Thanks. - Jeff From: Bogdan-Andrei Iancu bog...@opensips.orgmailto:bog...@opensips.org Date: Wed, 13 Apr 2011 09:28:35 -0400 To: OpenSIPS users mailling list users@lists.opensips.orgmailto:users@lists.opensips.org Cc: Jeff Pyle jp...@fidelityvoice.commailto:jp...@fidelityvoice.com Subject: Re: [OpenSIPS-Users] uac_replace_from auto mode with to_tag ignores display name Hi Guys, actually it is not a configuration problem at all - the UAC module does not restore the DISPLAY part of FROM/TO, but only the URI part (in sequential requests). Regards, Bogdan On 04/12/2011 05:57 PM, Jeff Pyle wrote: Razvan, On the initial INVITE the first parameter is not set to . I run the function as follows: uac_replace_from($var(id_namereplace), sip:$avp(s:id_num)@$Risip:$avp(s:id_num)@$Ri); On the initial INVITE, both the display name and the URI are updated correctly, that is, with the values put into the function. The problem happens in loose_route when the URI is updated but the display name is not. To get around the problem of the original display name leaking through loose route, I have added the following functions to neutralize it completely. No display name on subsequent requests is better than the wrong name: if (is_direction(downstream)) uac_replace_from(,); if (is_direction(upstream)) uac_replace_to(,); This does effectively remove the display name without touching the URI. But shouldn't the display name be updated automatically (in auto mode) just as the URI is? - Jeff From: Razvan Crainea razvancrai...@opensips.orgmailto:razvancrai...@opensips.org Reply-To: OpenSIPS users mailling list users@lists.opensips.orgmailto:users@lists.opensips.org Date: Tue, 12 Apr 2011 03:42:44 -0400 To: users@lists.opensips.orgmailto:users@lists.opensips.org users@lists.opensips.orgmailto:users@lists.opensips.org Subject: Re: [OpenSIPS-Users] uac_replace_from auto mode with to_tag ignores display name Hello, Jeff, Please make sure that the first parameter is not set to . As you can see here[1], if the first parameter of uac_replace_from method is , it removes the Display name. Regards, Razvan [1] http://www.opensips.org/html/docs/modules/devel/uac.html#id292701 On 04/11/2011 07:03 PM, Jeff Pyle wrote: Hello, I run uac_replace_from (auto mode) in a branch_route. Subsequents requests for the same dialog (with to_tag, through loose_route) have the From URI updated correctly, but the display name isn't. Is this a misconfiguration on my part, by design, or a bug? - Jeff ___ Users mailing list Users@lists.opensips.orgmailto:Users@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.orgmailto:Users@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS eBootcamp - 2nd of May 2011 OpenSIPS solutions and know-how ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Could I build a SIP firewall with OpenSIPS?
Hi there, I am investigating OpenSIPS for use in my company's VOIP network. I'm wondering if I could get a little advice on a design I am considering? The problem: We currently have a VOIP network built around a propriety SIP proxy which we are discovering appears to have a number of security weaknesses. The most significant of these is it's inability to tear down calls in progress once a user's balance has hit zero and having no ability to limit the channels that a user has open. This could potentially cripple our business due to the losses we are experiencing from fraud. A very early draft of my solution: I have noticed the OpenSIPS module userblacklist ( http://www.opensips.org/html/docs/modules/1.6.x/userblacklist.html ) and believe that this could solve our problems. I have other code running elsewhere on our network which is able to identify fraudulent calls - I just need a way of killing said calls and stopping the fraud in progress. It seems with this module I could call a web service on the OpenSIPS server, add and remove SIP uris from the blacklist database table and then call the module MI function via XML-RPC to update the list and cut off the call. (At least I am hoping it could do this - can the blacklist block calls in progress?) Assuming the userblacklist module will do what I hope, I have a question about how to slot the OpenSIPS server into our network. In an ideal world, I would run the OpenSIPS server in stateless mode so that is scales well, and do nothing more with the SIP traffic apart from forward on non-blocked calls to our existing propriety SIP proxy and block banned SIP uris from progressing any further. The main question I have is can the userblacklist module be run in stateless mode and is it possible for OpenSIPS to forward on traffic to another SIP proxy for registration. In effect I guess I am trying to build some kind of SIP firewall out of OpenSIPS but I don't know if this is possible. Any advice / constructive criticism from the knowledgeable people on this list would be massively appreciated! Sincerely, Dan. (If it's okay I will keep my surname and company name anonymous due to the public nature of this list and the fraud problems that we have been experiencing.) ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] dlg_validate_dialog errors in loose_route
Hi Jeff,
Well, life sucks.You see, the UA you use is re-ordering the URI
params...This is perfectly allowed from RFC point of view, but is
bullshit in real life. So your UA is compliant, but not fairplay :)
The only solution to this is to extend the SIP URI matching from
simple string comparison, to RFC-wise comp - parsing the URI, checking
username, domain, params, etc.I tried to avoid this as much as
possible as it BS to me
Regards,
Bogdan
On 04/13/2011 05:34 AM, Jeff Pyle wrote:
This thing is picky… The validation failed with the following values
in the log entry:
req=[sip:opensips IP;*lr;r2=on*;ftag=gK0706089a;did=e17.bfb88ba7],
dlg=[sip:opensips IP;*r2=on;lr*;ftag=gK0706089a;did=e17.bfb88ba7]
Not quite sure what to say about this one.
- Jeff
From: Jeff Pyle jp...@fidelityvoice.com mailto:jp...@fidelityvoice.com
Reply-To: OpenSIPS users mailling list users@lists.opensips.org
mailto:users@lists.opensips.org
Date: Mon, 11 Apr 2011 10:15:11 -0400
To: OpenSIPS users mailling list users@lists.opensips.org
mailto:users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] dlg_validate_dialog errors on BYE and
ACK in loose_route
Indeed! I hadn't noticed the difference in the dlg vs req sections of
the debug message.
I shall try exactly as you suggest. Thanks.
- Jeff
From: Vlad Paiu vladp...@opensips.org mailto:vladp...@opensips.org
Reply-To: OpenSIPS users mailling list users@lists.opensips.org
mailto:users@lists.opensips.org
Date: Mon, 11 Apr 2011 06:13:32 -0400
To: users@lists.opensips.org mailto:users@lists.opensips.org
users@lists.opensips.org mailto:users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] dlg_validate_dialog errors on BYE and
ACK in loose_route
Hello Jeff,
It's not that the dialog is already torn down by the time the BYE gets
to that particular portion of script.
It's complaining about the fact that at the dialog creation, the route
had the lr=on parameter, and at BYE time, the parameter has been
stripped and set
just to lr.
This should not happen in a regular scenario, as other SIP entities
should not explicitly modify the content of Route headers recorded at
Invite time.
You could try to check the enable_full_lr ( [1] ) parameter, and
onlyattach lr instead of lr=on, and see if this fixes the behavior.
[1] http://www.opensips.org/html/docs/modules/devel/rr.html#id250149
Regards,
--
Vlad Paiu
OpenSIPS Developer
On 04/09/2011 10:32 PM, Jeff Pyle wrote:
Hello,
I'm trying a new chunklet of config in loose_route(). I believe this
came from a documentation page somewhere, so I don't pretend to take
credit for the concept.
# Clean up dialog data if necessary
if ($DLG_status!=NULL !validate_dialog()) {
xlog(L_INFO, Unable to validate
dialog, fixing - $hdr(CSeq) on $ci\n);
fix_route_dialog();
}
I send the first batch of pseudo-production traffic through this
config today and I ended up with a metric ton of:
ERROR:dialog:dlg_validate_dialog: Check failed for routenumber 0.
req=[sip:opensips-IP?;lr;ftag=23ddd50-0-13c4-1f179b-78884527-1f179b;did=45b.b972314],dlg=[sip:opensips-IP;lr=on;ftag=23ddd50-0-13c4-1f179b-78884527-1f179b;did=45b.b972314]
And, the xlogs from the above line:
Unable to validate dialog, fixing - 3 BYE on callid
It showed up on a number of BYEs and ACKs. My dialog module config
is as follows:
# - dialog params -
modparam(dialog, dlg_flag, 4)
modparam(dialog, bye_on_timeout_flag, 4)
modparam(dialog, default_timeout, 21600)
modparam(dialog|sst, timeout_avp, $avp(s:dialog_timeout))
modparam(dialog, dlg_extra_hdrs, Hint: dialog expired\r\n)
modparam(dialog, dlg_match_mode, 1) # 0 = DID_ONLY; 1 = DID
first, SIP second; 2 = SIP only
modparam(dialog, db_url, mysql://osuer:ospass@dbcluster/osdb)
modparam(dialog, table_name, dialog_1)
modparam(dialog, db_mode, 1) # 1 = Realtime to DB; 2 = delayed;
3 = on shutdown
modparam(dialog, profiles_with_value, 711calls; 729calls; calls)
create_dialog() runs on all initial INVITEs.
Is this type of behavior anything close to normal? What might cause
it? My immediate fix is to simply comment out this portion of the
config, but I'm afraid I might be masking a larger issue. Any
suggestions would be great.
Just had a thought as I was about to send this email. Perhaps this
is because by the time the BYE gets to this portion of the script,
the dialog is already torn down? Could it be that simple, just add
if !(is_method(BYE) || is_method(ACK)) to the top line of this
config portion?
- Jeff
___
Users mailing list
Users@lists.opensips.orghttp://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] Group ID problem
Hi Guys,
yes, the prototype of the function was changed exactly because of this
kind of problems - you cannot use the script function to return values
via return code (this is used for something else), so the returned value
is passed now via an output parameter.
Regards,
Bogdan
On 04/08/2011 09:27 PM, Duane Larson wrote:
I believe you need to have something like get_source_address(var(x))
That is probably the issue. Bogdan mentions in a previous mailing
list issue that the prototype of the function was changed.
Sent from Droid
On Apr 8, 2011 1:17 PM, Wesley Volcov wesleyvol...@gmail.com
mailto:wesleyvol...@gmail.com wrote:
Hey Duane,
I have others groups id in my address table, that's why my source
address
function have 0, to check all groupid.
But my is problem is the groupid that the function
get_source_group(); is
getting..
Regards,
On 8 April 2011 14:14, Duane Larson duane.lar...@gmail.com
mailto:duane.lar...@gmail.com wrote:
I your check source address function shouldn't you have a 1 instead
of a 0
since that is what you have in your permissions table.
Sent from Droid
On Apr 8, 2011 12:03 PM, Wesley Volcov wesleyvol...@gmail.com
mailto:wesleyvol...@gmail.com wrote:
Hello list,
I'm using opensips 1.6.2.
I have the follow configuration in my AUTH route:
if (check_source_address(0,$avp(i:9))) {
$avp(i:10) = get_source_group();
xlog(L_INFO, GroupID: $avp(i:10));
}
In my address table, i have:
grp = 1
ip = 192.68.10.10
mask = 32
port = 0
proto = UDP
When I send a call, from a gw authenticated via IP, it gets the
follow
group
ID:
GroupID: 4294967295
And then, it can not found a route, because all the routes are
configured
with groupid 1. But, I don't know how opensips is getting this
groupid..
Could someone helpe me?
Thanks a lot!
--
Wesley Volcov
Email: wesleyvol...@gmail.com mailto:wesleyvol...@gmail.com
Messenger: vol...@live.com mailto:vol...@live.com
Mobile: +55 11 9989-5348
Website: http://volcov.blogspot.com
___
Users mailing list
Users@lists.opensips.org mailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Wesley Volcov
Email: wesleyvol...@gmail.com mailto:wesleyvol...@gmail.com
Messenger: vol...@live.com mailto:vol...@live.com
Mobile: +55 11 9989-5348
Website: http://volcov.blogspot.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and know-how
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Group ID problem
Hey Bogdan,
But that is the function syntax in opensips 1.6.2. I think it was changed in
opensips 1.6.3 version..
So.. Should I upgrade my opensips server?
Cheers
On 13 April 2011 11:56, Bogdan-Andrei Iancu bog...@opensips.org wrote:
Hi Guys,
yes, the prototype of the function was changed exactly because of this kind
of problems - you cannot use the script function to return values via return
code (this is used for something else), so the returned value is passed now
via an output parameter.
Regards,
Bogdan
On 04/08/2011 09:27 PM, Duane Larson wrote:
I believe you need to have something like get_source_address(var(x))
That is probably the issue. Bogdan mentions in a previous mailing list
issue that the prototype of the function was changed.
Sent from Droid
On Apr 8, 2011 1:17 PM, Wesley Volcov wesleyvol...@gmail.com wrote:
Hey Duane,
I have others groups id in my address table, that's why my source address
function have 0, to check all groupid.
But my is problem is the groupid that the function get_source_group(); is
getting..
Regards,
On 8 April 2011 14:14, Duane Larson duane.lar...@gmail.com wrote:
I your check source address function shouldn't you have a 1 instead of a
0
since that is what you have in your permissions table.
Sent from Droid
On Apr 8, 2011 12:03 PM, Wesley Volcov wesleyvol...@gmail.com
wrote:
Hello list,
I'm using opensips 1.6.2.
I have the follow configuration in my AUTH route:
if (check_source_address(0,$avp(i:9))) {
$avp(i:10) = get_source_group();
xlog(L_INFO, GroupID: $avp(i:10));
}
In my address table, i have:
grp = 1
ip = 192.68.10.10
mask = 32
port = 0
proto = UDP
When I send a call, from a gw authenticated via IP, it gets the follow
group
ID:
GroupID: 4294967295
And then, it can not found a route, because all the routes are
configured
with groupid 1. But, I don't know how opensips is getting this
groupid..
Could someone helpe me?
Thanks a lot!
--
Wesley Volcov
Email: wesleyvol...@gmail.com
Messenger: vol...@live.com
Mobile: +55 11 9989-5348
Website: http://volcov.blogspot.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Wesley Volcov
Email: wesleyvol...@gmail.com
Messenger: vol...@live.com
Mobile: +55 11 9989-5348
Website: http://volcov.blogspot.com
___
Users mailing
listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and know-how
--
Wesley Volcov
Email: wesleyvol...@gmail.com
Messenger: vol...@live.com
Mobile: +55 11 9989-5348
Website: http://volcov.blogspot.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Group ID problem
Hey Bogdan,
I'll upgrade my server to the last version.
But anyway, thank you so much for your attention!!
Best Regards,
On 13 April 2011 12:33, Bogdan-Andrei Iancu bog...@opensips.org wrote:
Hi Wesley,
that will be the right way - if not really possible, I can try to make you
a backport only for this item.
Regards,
Bogdan
On 04/13/2011 06:06 PM, Wesley Volcov wrote:
Hey Bogdan,
But that is the function syntax in opensips 1.6.2. I think it was changed
in opensips 1.6.3 version..
So.. Should I upgrade my opensips server?
Cheers
On 13 April 2011 11:56, Bogdan-Andrei Iancu bog...@opensips.org wrote:
Hi Guys,
yes, the prototype of the function was changed exactly because of this
kind of problems - you cannot use the script function to return values via
return code (this is used for something else), so the returned value is
passed now via an output parameter.
Regards,
Bogdan
On 04/08/2011 09:27 PM, Duane Larson wrote:
I believe you need to have something like get_source_address(var(x))
That is probably the issue. Bogdan mentions in a previous mailing list
issue that the prototype of the function was changed.
Sent from Droid
On Apr 8, 2011 1:17 PM, Wesley Volcov wesleyvol...@gmail.com wrote:
Hey Duane,
I have others groups id in my address table, that's why my source
address
function have 0, to check all groupid.
But my is problem is the groupid that the function get_source_group();
is
getting..
Regards,
On 8 April 2011 14:14, Duane Larson duane.lar...@gmail.com wrote:
I your check source address function shouldn't you have a 1 instead of
a 0
since that is what you have in your permissions table.
Sent from Droid
On Apr 8, 2011 12:03 PM, Wesley Volcov wesleyvol...@gmail.com
wrote:
Hello list,
I'm using opensips 1.6.2.
I have the follow configuration in my AUTH route:
if (check_source_address(0,$avp(i:9))) {
$avp(i:10) = get_source_group();
xlog(L_INFO, GroupID: $avp(i:10));
}
In my address table, i have:
grp = 1
ip = 192.68.10.10
mask = 32
port = 0
proto = UDP
When I send a call, from a gw authenticated via IP, it gets the
follow
group
ID:
GroupID: 4294967295
And then, it can not found a route, because all the routes are
configured
with groupid 1. But, I don't know how opensips is getting this
groupid..
Could someone helpe me?
Thanks a lot!
--
Wesley Volcov
Email: wesleyvol...@gmail.com
Messenger: vol...@live.com
Mobile: +55 11 9989-5348
Website: http://volcov.blogspot.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Wesley Volcov
Email: wesleyvol...@gmail.com
Messenger: vol...@live.com
Mobile: +55 11 9989-5348
Website: http://volcov.blogspot.com
___
Users mailing
listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and know-how
--
Wesley Volcov
Email: wesleyvol...@gmail.com
Messenger: vol...@live.com
Mobile: +55 11 9989-5348
Website: http://volcov.blogspot.com
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and know-how
--
Wesley Volcov
Email: wesleyvol...@gmail.com
Messenger: vol...@live.com
Mobile: +55 11 9989-5348
Website: http://volcov.blogspot.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] function with 6 parameters
Thank you Razvan.
Bogdan
--- On Wed, 4/13/11, Razvan Crainea razvancrai...@opensips.org wrote:
From: Razvan Crainea razvancrai...@opensips.org
Subject: Re: [OpenSIPS-Users] function with 6 parameters
To: rad bogdan bogdan_rad2...@yahoo.com
Cc: users@lists.opensips.org
Date: Wednesday, April 13, 2011, 5:28 PM
Hello, Bogdan,
The problem is that the function you are using to fetch the values
of the pseudo variables (fixup_get_svalue) uses static buffers to
store the string values. These buffers are only 5 an they are used
circularly. That's why the first value is the same with the last
one.
The best solution is to make sure you don't use more than 5 buffers
concurrently, preferably process the value right after fetching it
(in your example print the value right after getting it). Another
solution is to use the pv_printf function where you can specify
your buffer. As a last resort you can increase the buffers number in
pvar.c (search PV_PRINT_BUF_NO definition).
Regards,
Razvan
On 04/13/2011 01:58 PM, rad bogdan wrote:
Hi Razvan,
I've applied the patch you gave me.
This is the output:
INFO:core:do_action: called test6(0x81b1398, 0x81b144c,
0x81b14b4, 0x81b151c, 0x81b1584, 0x81b15ec)
INFO:test:test6: arg1: [789]
INFO:test:test6: arg2: [222]
INFO:test:test6: arg3: [333]
INFO:test:test6: arg4: [123]
INFO:test:test6: arg5: [456]
INFO:test:test6: arg6: [789]
INFO:core:fix_actions: fixed test6[1] 0x81b1398
INFO:core:fix_actions: fixed test6[2] 0x81b144c
INFO:core:fix_actions: fixed test6[3] 0x81b14b4
INFO:core:fix_actions: fixed test6[4] 0x81b151c
INFO:core:fix_actions: fixed test6[5] 0x81b1584
INFO:core:fix_actions: fixed test6[6] 0x81b15ec
This is the code from opensips.cfg:
$var(var1) = 111;
$var(var2) = 222;
$var(var3) = 333;
$avp(s:avp1) = 123;
$avp(s:avp2) = 456;
$avp(s:avp3) = 789;
test6($var(var1), $var(var2), $var(var3),
$avp(s:avp1), $avp(s:avp2), $avp(s:avp3));
Attached is the module.
Thanks,
Bogdan
--- On Mon, 4/11/11, Razvan Crainea razvancrai...@opensips.org
wrote:
From: Razvan Crainea razvancrai...@opensips.org
Subject: Re: [OpenSIPS-Users] function with 6 parameters
To: users@lists.opensips.org
Date: Monday, April 11, 2011, 1:45 PM
Hello Bogdan,
I implemented a similar test function that takes 6
parameters.
All values seems to be in the correct order in both
fixup function and triggered function.
I attached a small patch that prints the value of the
parameters right after the fixup function and then
again before the function is called.
Please apply this patch and then check if the
parameters values and order match between the fixup
and triggered function?
Regards,
Razvan
On 04/06/2011 05:51 PM, rad bogdan wrote:
Hi
Bogdan,
The inversion is only in the triggered
function.
The arguments are passed correctly from left
to right to the fixup function.
The triggered function is:
test_function(struct sip_msg *msg, char
*arg1, char *arg2, char* arg3, char* arg4,
char* arg5, char* arg6)
{
str arg1_s = {NULL, 0};
if(arg1 == NULL || fixup_get_svalue(msg,
(gparam_p)arg1, arg1_s) != 0)
{
LM_ERR(Invalid arg1
Re: [OpenSIPS-Users] Problem on handing prefixed contact number from Cisco GW
Hello Bogdan, Thanks for your reply. I tryed and it worked as I recall. I needed the prefix to do some comparison but I fixed it with some fixed value so for now everything is working fine. Best Regards and Thanks, Joel Oliveira -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Problem-on-handling-prefixed-contact-number-from-Cisco-GW-tp6230782p6270179.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] dlg_validate_dialog errors in loose_route
Hi Jeff,
On 04/13/2011 06:23 PM, Jeff Pyle wrote:
Bogdan,
Don't hold back…let's hear how you really feel.:)
Do not make me start :P
I understand your position. Unfortunately since there are UAs that do
this, and they RFC compliant in their behavior, the validate_dialog()
function is less useful in the real world. I've had to remove it from
my configs.
I agree with you - we like it or not, needs yo comply with the RFC.
As today we had the monthly IRC meeting, I brought this into discussion
(SIP-wise URI matching) and already have an action plan set (together
with Ovidiu Sas).
I'm fighting a similar situation regarding the behavior of the
uac_replace_from function. It seems that Acme SBCs replace the value
of the From header (old To header) on new requests within a dialog,
and this breaks the uac_replace_from function. I've cited the second
paragraph of section 12.2.1.1 of RFC 3261. The carrier I'm fighting
with now reads this mandatory reflection behavior as part of the old
RFC 2543, not 3261. They aren't willing to put any more time into
configuring their Acme to maintain the headers. I work with another
carrier partner who also uses Acme who was able to make the change.
I'm trying to get the details from the second carrier so I can share
them with the first.
Life is complicated with RFCs...even we all read the same papers, we
have as many opinions as number of readers :P.
BTW, have you tested the ACK patch I sent you ?
Regards,
Bogdan
- Jeff
From: Bogdan-Andrei Iancu bog...@opensips.org
mailto:bog...@opensips.org
Reply-To: OpenSIPS users mailling list users@lists.opensips.org
mailto:users@lists.opensips.org
Date: Wed, 13 Apr 2011 10:54:00 -0400
To: users@lists.opensips.org mailto:users@lists.opensips.org
users@lists.opensips.org mailto:users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] dlg_validate_dialog errors in loose_route
Hi Jeff,
Well, life sucks.You see, the UA you use is re-ordering the URI
params...This is perfectly allowed from RFC point of view, but is
bullshit in real life. So your UA is compliant, but not fairplay :)
The only solution to this is to extend the SIP URI matching from
simple string comparison, to RFC-wise comp - parsing the URI, checking
username, domain, params, etc.I tried to avoid this as much as
possible as it BS to me
Regards,
Bogdan
On 04/13/2011 05:34 AM, Jeff Pyle wrote:
This thing is picky… The validation failed with the following values
in the log entry:
req=[sip:opensips IP;*lr;r2=on*;ftag=gK0706089a;did=e17.bfb88ba7],
dlg=[sip:opensips IP;*r2=on;lr*;ftag=gK0706089a;did=e17.bfb88ba7]
Not quite sure what to say about this one.
- Jeff
From: Jeff Pyle jp...@fidelityvoice.com
mailto:jp...@fidelityvoice.com
Reply-To: OpenSIPS users mailling list users@lists.opensips.org
mailto:users@lists.opensips.org
Date: Mon, 11 Apr 2011 10:15:11 -0400
To: OpenSIPS users mailling list users@lists.opensips.org
mailto:users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] dlg_validate_dialog errors on BYE and
ACK in loose_route
Indeed! I hadn't noticed the difference in the dlg vs req sections
of the debug message.
I shall try exactly as you suggest. Thanks.
- Jeff
From: Vlad Paiu vladp...@opensips.org mailto:vladp...@opensips.org
Reply-To: OpenSIPS users mailling list users@lists.opensips.org
mailto:users@lists.opensips.org
Date: Mon, 11 Apr 2011 06:13:32 -0400
To: users@lists.opensips.org mailto:users@lists.opensips.org
users@lists.opensips.org mailto:users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] dlg_validate_dialog errors on BYE and
ACK in loose_route
Hello Jeff,
It's not that the dialog is already torn down by the time the BYE
gets to that particular portion of script.
It's complaining about the fact that at the dialog creation, the
route had the lr=on parameter, and at BYE time, the parameter has
been stripped and set
just to lr.
This should not happen in a regular scenario, as other SIP entities
should not explicitly modify the content of Route headers recorded at
Invite time.
You could try to check the enable_full_lr ( [1] ) parameter, and
onlyattach lr instead of lr=on, and see if this fixes the behavior.
[1] http://www.opensips.org/html/docs/modules/devel/rr.html#id250149
Regards,
--
Vlad Paiu
OpenSIPS Developer
On 04/09/2011 10:32 PM, Jeff Pyle wrote:
Hello,
I'm trying a new chunklet of config in loose_route(). I believe
this came from a documentation page somewhere, so I don't pretend to
take credit for the concept.
# Clean up dialog data if necessary
if ($DLG_status!=NULL !validate_dialog()) {
xlog(L_INFO, Unable to validate
dialog, fixing - $hdr(CSeq) on $ci\n);
fix_route_dialog();
}
I send the first batch of pseudo-production traffic through this
config today and I ended up with a metric ton
Re: [OpenSIPS-Users] db_url confusing issue
Hi Brett, Believe it or not, but this happened to my too, several times. IMHO, the proper approach will be have an empty db_url for the modules, so that you may get a warning or so when trying to use a module without explicitly setting the db_url. Default, hidden params may be dangerous here Regards, Bogdan On 04/08/2011 05:56 PM, Brett Nemeroff wrote: Hello All, I just ran into an issue that I think others might also run into. So I just added dialog module to an existing configuration that already had a few db_urls specified for other modules. I forgot to add the db_url for the dialog module. Because of this, the dialog module (without warning) added it's own db_url. Of course, the default db_url didn't work and I got an access denied error in my logs. This took me a good 10 minutes to track down. I couldn't figure out why it wasn't logging in. to make matters worse, I'm using the username 'opensips' so the log just looks like I must have mistyped something: Apr 8 10:41:19 [16494] ERROR:db_mysql:db_mysql_connect: driver error(1045): Access denied for user 'opensips'@'localhost' (using password: YES) I really think that if a module is going to init with a default db_url, that it should probably have a WARNING in the logs. something like: Apr 8 XX:XX:XX [] WARNING:db_mysql:Using default db_url for module 'dialog'. You might want to change this If I had seen that, I'd know that I needed to set the db_url for the dialog module.. I'm pretty sure this came up sometime before.. Thanks, Brett ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS eBootcamp - 2nd of May 2011 OpenSIPS solutions and know-how ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_url confusing issue
On Wed, Apr 13, 2011 at 2:55 PM, Bogdan-Andrei Iancu bog...@opensips.orgwrote: Hi Brett, Believe it or not, but this happened to my too, several times. IMHO, the proper approach will be have an empty db_url for the modules, so that you may get a warning or so when trying to use a module without explicitly setting the db_url. Default, hidden params may be dangerous here Heh, I'm glad to hear that actually. I felt pretty crazy for about 10 minutes trying to figure out what what going on. :) I agree with you. I think default db_urls are asking for trouble: 1. If it does work, you by design have a security flaw (everyone knows your DB credentials) 2. If it doesn't work, there's no way of telling what exactly it's doing (where did the params come from) I think I understand the reasoning behind the default db_urls as it pertains the to auto installation of the database. But perhaps those processes should be better linked. Like default db_url can be imported from opensipsctlrc :D That's probably out of the 1.X realm eh? In my personal opinion, default db_urls allow for sloppy coding that probably helps new users get started quicker. But probably also will lead them down the path of not setting up the connections properly (securely). That's my $0.02 -Brett ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_url confusing issue
On 04/13/2011 11:12 PM, Brett Nemeroff wrote: On Wed, Apr 13, 2011 at 2:55 PM, Bogdan-Andrei Iancu bog...@opensips.org mailto:bog...@opensips.org wrote: Hi Brett, Believe it or not, but this happened to my too, several times. IMHO, the proper approach will be have an empty db_url for the modules, so that you may get a warning or so when trying to use a module without explicitly setting the db_url. Default, hidden params may be dangerous here Heh, I'm glad to hear that actually. I felt pretty crazy for about 10 minutes trying to figure out what what going on. :) I agree with you. I think default db_urls are asking for trouble: 1. If it does work, you by design have a security flaw (everyone knows your DB credentials) 2. If it doesn't work, there's no way of telling what exactly it's doing (where did the params come from) I think I understand the reasoning behind the default db_urls as it pertains the to auto installation of the database. But perhaps those processes should be better linked. Like default db_url can be imported from opensipsctlrc :D That's probably out of the 1.X realm eh? In my personal opinion, default db_urls allow for sloppy coding that probably helps new users get started quicker. But probably also will lead them down the path of not setting up the connections properly (securely). Or maybe, to make everyone happy, to have a global cfg parameter for defining a default db_url. This will be used to populate the db_urls from the module. So, the default value will be explicitly set in the opensips cfg - no way to miss it, also easy to roll out a simple default cfg. Regards, Bogdan -- Bogdan-Andrei Iancu OpenSIPS eBootcamp - 2nd of May 2011 OpenSIPS solutions and know-how ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_url confusing issue
On Wed, Apr 13, 2011 at 3:22 PM, Bogdan-Andrei Iancu bog...@opensips.orgwrote: Or maybe, to make everyone happy, to have a global cfg parameter for defining a default db_url. This will be used to populate the db_urls from the module. So, the default value will be explicitly set in the opensips cfg - no way to miss it, also easy to roll out a simple default cfg. Yeah,I like that.. easy to see, easy to change.. easy to remove You got my vote. :) -Brett ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] db_url confusing issue
Seconded… From: Brett Nemeroff br...@nemeroff.commailto:br...@nemeroff.com Reply-To: OpenSIPS users mailling list users@lists.opensips.orgmailto:users@lists.opensips.org Date: Wed, 13 Apr 2011 16:24:45 -0400 To: Bogdan-Andrei Iancu bog...@opensips.orgmailto:bog...@opensips.org Cc: users@lists.opensips.orgmailto:users@lists.opensips.org users@lists.opensips.orgmailto:users@lists.opensips.org Subject: Re: [OpenSIPS-Users] db_url confusing issue On Wed, Apr 13, 2011 at 3:22 PM, Bogdan-Andrei Iancu bog...@opensips.orgmailto:bog...@opensips.org wrote: Or maybe, to make everyone happy, to have a global cfg parameter for defining a default db_url. This will be used to populate the db_urls from the module. So, the default value will be explicitly set in the opensips cfg - no way to miss it, also easy to roll out a simple default cfg. Yeah,I like that.. easy to see, easy to change.. easy to remove You got my vote. :) -Brett ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
