[OpenSIPS-Users] Top hiding scenario using rtpproxy
Hello list,
I've been played with b2bua module using the top hiding scenario
using 1.6.2 opensips version.
It seems to be working fine, but I need to call force_rtp_proxy() for
the INVITE requests to force the uac send rtp to rtpproxy IP.
I called it in the script at this point:
if(is_method(INVITE) !(src_ip == xxx.xx.0.230)) {
force_rtp_proxy();
b2b_init_request(top hiding);
exit;
}
It didn't work.
Doesn't the function work with b2bua and top hiding scenario? If it
works, what am I doing wrong?
Thanks.
--
Adelson
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] opensips process dying (dialplan module?)
Hey Bogdan, I changed it and now it is working. Thank you very much. Adelson. On Wed, Aug 25, 2010 at 12:40 PM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: In SVN, this is already changed from attrs_avp to gw_attrs_avp Regards, Bogdan Adelson O. Junior wrote: Hi Bogdan, Thanks for replying. I've updated for 1.6.3 svn tag and I'am getting an error about drouting modparam: attrs_avp. Note: this modparam is working with the 1.6.3 package from mirrors. This is occuring in svn tag only. Thanks, Adelson. Aug 24 19:28:24 OPENSIPS02 opensips: ERROR:core:set_mod_param_regex: parameter attrs_avp not found in module drouting Aug 24 19:28:24 OPENSIPS02 opensips: CRITICAL:core:yyerror: parse error in config file, line 99, column 36-37: Parameter attrs_avp not found in module drouting - can't set Aug 24 19:28:24 OPENSIPS02 opensips: ERROR:core:main: bad config file (1 errors) On Tue, Aug 24, 2010 at 6:07 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hello Adelson, better upgrade to latest 1.6 version (1.6.3) from SVN - it contains all recent fixes on 1.6 branch. Take care that the regexp engine for dialplan module was changed from 1.6.2 to 1.6.3 as old one (trex) was bogus and unmaintained. See http://www.opensips.org/Resources/DocsMigration162to163 The upgrade should be be smooth, no script or DB changes. Regards, Bogdan Adelson O. Junior wrote: Hi list, my opensips process is dying constantly. According the dump core, it seems (for me) to be a function in dialplan that is causing it. Follows the dump from gdb. Is someone facing this kind of problem? opensips version is: opensips 1.6.1-notls (i386/linux) Thanks, -- Adelson ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 20 - 24 September 2010, Frankfurt, Germany www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 20 - 24 September 2010, Frankfurt, Germany www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Adelson ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] opensips process dying (dialplan module?)
Hi list,
my opensips process is dying constantly.
According the dump core, it seems (for me) to be a function in
dialplan that is causing it.
Follows the dump from gdb.
Is someone facing this kind of problem?
opensips version is: opensips 1.6.1-notls (i386/linux)
Thanks,
Core was generated by `/usr/local/sbin/opensips -P
/var/run/opensips.pid -m 256'.
Program terminated with signal 11, Segmentation fault.
#0 0x00e450de in rule_translate (msg=0x81dbeac, string=...,
rule=0xa821fda0, result=0xbfc34c4c) at dp_repl.c:192
192 memcpy(result-s + result-len,
match.begin, match.len);
(gdb) bt full
#0 0x00e450de in rule_translate (msg=0x81dbeac, string=...,
rule=0xa821fda0, result=0xbfc34c4c) at dp_repl.c:192
repl_nb = 0
offset = 0
token = {offset = 0, size = 2, type = REPLACE_NMATCH, u =
{nmatch = 2, c = 2 '\002', spec = {type = PVT_NULL, getf = 0,
setf = 0, pvp = {pvn = {type = 1, u = {isname = {type =
0, name = {n = 9534827, s = {s = 0x917d6b \201É\302\v,
len = -1}}}, dname = 0x0}}, pvi = {type =
53, u = {ival = 10197728, dval = 0x9b9ae0}}, pvv = {
s = 0xbfc362ec
\017\352\n\b\230\353\033\b\254\276\035\b, len = 9531122}}, pvc =
0xa821f964, trans = 0xe4721c}}}
subst_comp = 0xa821fc8c
repl_comp = 0xa821fc14
match = {begin = 0x830457a 1150212...@200.225.81.91:5060, len = -3366}
sv = {rs = {s = 0x4a98 Address 0x4a98 out of bounds, len =
136167084}, ri = 137377864, flags = 12}
uri = 0x0
__FUNCTION__ = rule_translate
#1 0x00e463eb in translate (msg=0x81dbeac, input=...,
output=0xbfc34c4c, idp=0xa821497c, attrs=0x0) at dp_repl.c:346
rulep = 0xa821fda0
indexp = value optimized out
rez = value optimized out
__FUNCTION__ = translate
#2 0x00e3d2f7 in dp_translate_f (msg=0x81dbeac, str1=0x81d6dd4
\001, str2=0x81d6e50 \001) at dialplan.c:368
dpid = 15
input = {s = 0x8304578 551150212...@200.225.81.91:5060, len = 12}
output = {s = 0xe4ec20 1150212...@200.225.81.91:5060, len = 0}
idp = 0xa821497c
repl_par = 0x81d6e50
attrs = {s = 0x81c7ee7 post_ruri_id), len = 12}
attrs_par = 0x0
__FUNCTION__ = dp_translate_f
#3 0x080546fd in do_action (a=0x81c845c, msg=0x81dbeac) at action.c:967
val_s = {s = 0x81dbeac \316#\001, len = 136120380}
aux = {s = 0x3bf816 \205\300\017\205b\001, len = 136035128}
ret = value optimized out
v = value optimized out
to = value optimized out
p = value optimized out
tmp = value optimized out
new_uri = value optimized out
end = value optimized out
crt = value optimized out
len = value optimized out
user = value optimized out
uri = {user = {s = 0x3ce110 \200\001, len = 136035128},
passwd = {s = 0x81c2155 post_ruri_id), len = -1077719320},
host = {s = 0x81c7fdc \001, len = 136167084}, port = {s =
0x4 Address 0x4 out of bounds, len = -1077719208}, params = {
s = 0x80aea0f
\211\306\...@\377\377\377\213m\020\211l$\b\213u\f\211t$\004\213s\f\211\064$\350\071\376\377\377\211ƅ\300\017---type
return to continue, or q return to quit---
\205\035\377\377\377\213u\020\211t$\b\213E\f\211D$\004\213{\030\211$\350\026\376\377\377\211\306\351\375\376\377\377\377$\275\254c\025\b\213}\020\211|$\b\213M\f\211L$\004\213S\f\211\024$\350\357\375\377\377\211ƃ,
incomplete sequence \370, len = 136085424},
headers = {s = 0x81dbeac \316#\001, len = 0}, port_no = 0,
proto = 0, type = 3217249364, transport = {s = 0x0, len = 256},
ttl = {s = 0x81dbeac \316#\001, len = -1077719352},
user_param = {s = 0x81d4384 \004, len = -1077719320}, maddr = {
s = 0x808f1a2
\205\300\017\205+\377\377\377\366E\354\001t\022\213\025\\9\025\b\213\r`9\025\b\211U\340\211M\344\213u\344\211u\274\213E\310\001\360\213}\024;\a\017\215W\001,
len = 15}, method = {s = 0x7 Address 0x7 out of bounds, len =
-1077719352}, lr = {
s = 0x6 Address 0x6 out of bounds, len = 1}, r2 = {s =
0x816752e , len = -1474188324}, transport_val = {s = 0x0,
len = 2}, ttl_val = {s = 0x9f3269b 0.0.0.0, len = 14},
user_param_val = {
s = 0x Address 0x out of bounds, len =
4}, maddr_val = {
s = 0xfff8 Address 0xfff8 out of bounds, len =
136120612}, method_val = {s = 0xe4e870 4G\001,
len = -1077717836}, lr_val = {s = 0x81c2155
post_ruri_id), len = 12}, r2_val = {s = 0x2 Address 0x2 out of
bounds,
len = 137380436}}
next_hop = {user = {s = 0x9f1a0c0 \001, len = -1077719656},
passwd = {s = 0x65eba1 \203\304\004[]É\366\215\274',
len = 166830272}, host = {s = 0x765c00 DXv, len =
-1077719624}, port = {
s = 0x683588
\213]\364\213u\370\213}\374\211\354]Ã\276|\003, len = 166830272},
params = {s = 0x0, len = -1077719560},
headers = {s = 0xc8817c
[OpenSIPS-Users] Big Record Route header
Hi list, We are facing a problem in our opensips proxy which it is receiving a Message too big error. Looking at the INVITE sent by our opensips I could notice a header that is so much bigger than usual: Record-Route. Follows the big RR header: Record-Route: sip:xxx.xxx.xxx.xxx;lr=on;ftag=user agent-7386;vsf=;vst=AAQEAgkEBQMGBAF2UyUNERwRCksaXAMBFRYYSw9BDkEPXGJy;did=b05.730dba51. Usual RR header: Record-Route: sip:xxx.xxx.xxx.xxx;lr=on;ftag=user-agent-2567;did=f6.671d2877 What is the difference between these 2 headers (the vsf, vst, did..what do they mean?) and how can I decrease the Record Route header length? Thanks in advice. -- Adelson ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Opensips logging issue?
Hello list, We were used to disable logs (debug=0) due to problems regarding to old Openser versions, and this became standard when we were going to migrate from Test to Production environments. But in the last one we forget this setting, and the log was enabled in Production Env, but no one was concerned about this, we though that this problem didn' t happen in Opensips, but it did. So, the problem itself is: The Opensips receive a INVITE packet, and took too long to forward. Looking in the log, we could see the lines about the processing of INVITE (instantly forwarded). But the time between the packet arrival (capturing by ngrep) and your lines in the log its about 2, 3, 4 seconds of difference. This problem, as I said we already faced it on openser versions, and we only have disable logs (debug=0) in opensips.cfg, restart the service and it got back to work normally. Did someone faced this problem? -- Adelson ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] uac_raplace_to twice in the branch
Hi Thomas, I could make it as you suggested. Thank you very much for your response. Adelson. On Sun, Apr 18, 2010 at 2:09 PM, Thomas Gelf tho...@gelf.net wrote: Just add another AVP, for example $avp(s:new_user). Set it to $var(pre_to_user) in your pre-routing code, to $var(post_to_user) in your post-routing code - change it as many times as you want. An then, at the end of your branch_route, call uac_replace_to with the new_user value (if such value is set) - that's all. Cheers, Thomas Adelson O. Junior wrote: We are implementing a solution using opensips which I have to replace the To header in a Pre_routing scenario and, depending of the routing, I have to replace the To header again, Post routing scenario. -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Adelson ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] uac_raplace_to twice in the branch
Hi list.
We are implementing a solution using opensips which I have to replace
the To header in a Pre_routing scenario and, depending of the
routing, I have to replace the To header again, Post routing
scenario. (a kind of I remove the prefix to execute some statement,
like dbalias, and then add the same or another prefix).
The big problem is that We built the scenario thinking to use
uac_replace_to twice (in Pre and Post routing scenario), but, when
it's really called twice it generates inconsistence in the To header,
according to the function documentation.
I would like to know if you guys have some idea how I can implement
this scenario, if uac_replace_to can not be used twice.
Thanks in advice.
Pre routing code:
if ( $avp(s:pre_to_id) != null ) {
dp_translate($avp(s:pre_to_id), $tU/$var(pre_to_user));
uac_replace_to($var(pre_to_user),sip:$var(pre_to_user)@$td) ;
xlog(L_INFO, PreRouting to TO: $rm gw:[$si:$sp]
ruri:[$ru] from:[$fu] to:[$tu] sourceip:[$si] callid:[$ci]\n);
}
...
Post routing code:
if ($avp(s:post_to_id) != null) {
dp_translate($avp(s:post_to_id), $tU/$var(post_to_user));
uac_replace_to($var(post_to_user),
sip:$var(post_to_user)@$td) ;
xlog(L_INFO, PostRouting to TO: $rm gw:[$si:$sp]
ruri:[$ru] from:[$fu] to:[$tu] sourceip:[$si] callid:[$ci]\n);
}
--
Adelson
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
