Re: [SR-Users] Issue with avp
On 2/14/11 8:40 PM, Amit Nepal wrote:
could someone help me on this please ?
Can you watch the mysql query logs and see if the rpid column is
selected along with the password for authentication from subscriber
table? Also, if you can run kamailio with debug=4 and send then output
here for such case would help troubleshooting.
This part was not changed for quite some time, so might be something
missing in the config or so.
Cheers,
Daniel
I have been trying to load rpid while loading credentials.
modparam("auth_db", "load_credentials", "$avp(i:123)=rpid")
Now, I am trying to do a check in my routing logic.
xlog("L_NOTICE","The avp is :$avp(i:123)"); (I dont get the value
here either, i can't see the value when i do avp_print()
if($avp(i:123)<5)
{
sl_send_reply("408","Message Here");
}
I dont get the value of avp at that place. And this is after
successful www/proxy_authenticate()
Thank you
Amit
On 2/10/2011 11:46 AM, Amit Nepal wrote:
Yes it is after successful www/proxy_authenticate()
Thank You
Amit Nepal
Systems Administrator
Phoenix Internet
Phone: 602-385-0731
602-234-0917#112
http://www.phoenixinternet.net
On 2/9/2011 11:54 PM, Daniel-Constantin Mierla wrote:
Hello,
On 2/9/11 10:35 PM, Amit Nepal wrote:
Hi,
I have been trying to load rpid while loading credentials.
modparam("auth_db", "load_credentials", "$avp(i:123)=rpid")
Now, I am trying to do a check in my routing logic.
xlog("L_NOTICE","The avp is :$avp(i:123)"); (I dont get the value
here either, i can't see the value when i do avp_print()
if($avp(i:123)<5)
{
sl_send_reply("408","Message Here");
}
I dont get the value of avp at that place. Any guidance please.
Is this piece of config after a successful www/proxy_authenticate()?
Cheers,
Daniel
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 1.5.4 and beyond - mhomed issue under Linux
Hi Marius, Thanks for the reply. I found the patch in the 1.5 CVS branch. By the way, the 1.5.5 source tarball in /pub/kamailio/1.5.5/src was created before this patch was written, so the patch is not in there. The tarball I created from the 1.5 branch did have it. Thanks again, Sean O'Donnell Senior Engineer uReach Technologies, Inc. On Mon, 14 Feb 2011, marius zbihlei (marius.zbih...@1and1.ro) wrote: On 02/11/2011 09:14 PM, Sean O'Donnell wrote: > Hi all, > Hello Sean, > I checked the GIT repository and noticed that there was a patch in forward.c for > this issue. Looks like it was done 11/4/2010. Two questions: > > 1) Is there any reason that patch didn't make it into Kamailio 3.1.2 ? > Indeed, there is no reason. Actually I have cherry-picked the patches into the 3.1 branch (commit_notice 3.1 3ec1e9 and 9ef0a1e). Thanks for noticing. > 2) Any reason I shouldn't apply that patck to my 1.5.4 release? > The patch was already applied to the svn 1.5 branch (don't know if the latest 1.5.5 tar ball has it) but you can install it from svn and you can find it there (commit 6050) Cheers Marius > Thanks, > Sean O'Donnell > Senior Engineer > uReach Technologies, Inc. > > > > > > On Thu, 10 Feb 2011, Sean O'Donnell (skodonn...@ureach.com) wrote: > > Hi all, > > I just started deploying Kamailio release 1.5.4, and I think there's an issue > with how Kamailio identifies an outgoing interface when mhomed is enabled under > Linux. > > I use Kamailio as a call distributor/proxy between a soft-switch/SBC and a > voicemail platform. It > runs on a CentOS 5.3 (Linux 2.6 kernel) host with two network interfaces and is > configured such that it listens on both interfaces. One interface (public > interface) handles traffic with the SBC, the other (private interface) handles > with the VM platform. The 'mhomed' option is enabled. > > After upgrading from 1.5.3 to 1.5.4, I started noticing problems with UDP > packets coming out of the public interface. After looking at some ngrep > captures on that interface, I noticed that some packets had the source IP > address of the private interface and also had Record-Route and Via headers for > the private interface only - no headers for the public interface were there. > > Usually when I see the wrong source IP in a UDP packet, it's an issue with how > routes are set up on the host. However, I had our network engineer double check > them, and they seem fine (no ambiguous routes). The fact that I captured these > messages on the public interface also indicates to me that the kernel is routing > the message correctly. The missing Record-Route and Via for the public > interface, however, lead me to believe that the proxy didn't correctly identify > the outgoing interface in the first place. > > After looking at the ChangeLog for 1.5.4, I noticed that the some new logic was > put in to improve performance when mhomed is enabled (r5971) in forward.c, and I > think this is the issue. > > As I understand it, prior to 1.5.4, when mhomed was enabled, Kamailio determined > the outgoing interface by creating a temporary UDP socket, invoking connect() on > the socket with the packet destination, then checking the source IP of the > socket that the kernel assigned using getsockname(). After the source address > was determined, the temp socket was closed closed. As of 1.5.4, this was > modified to reuse the temporary socket and just re-invoking connect() with a new > destination address. > > The problem with the enhancement is that Linux (again, at least in the 2.6 > kernels I'm using) > doesn't seem to rebind a new source address to the socket when connect() is > called more than once on > a UDP socket. Instead, it keeps the original one, and thus the wrong interface > is assumed. > > I wrote a small program to confirm this - basically creates a UDP socket, calls > connect()/getsockname() > multiple times using different destination addresses. I ran it on several 2.6 > kernels, including > Centos4.x and Centos5. The result was always that the source address of the > socket wasn't changed after the first connect(), regardless of the destination > address. The only way I could get it work as > required was to first do a connect() using a zero'd out AF_UNSPEC address before > doing the > connect() to the remote address. I also ran it on Solaris and it worked. Go > figure. > > I've downloaded the latest stable release (3.1.2) but I think the issue is still > there, and I don't see > anything in the user groups that addresses this. > > Any help would be appreciated. > > Thanks, > > Sean > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-user
[SR-Users] Kamailio 1.5.5 No TLS Segmentation Fault
Hello, We have been having a problem with Kamilio faulting and dumping core files on occasion. I have not been able to reproduce the failure at will, but notice the back trace seems to point toward actions with the dialogue. Below is from a backtrace of a core file from just a few minutes ago. Can anyone determine what may have caused the system to error and stop processing? Thanks Stagg Core was generated by `/sbin/kamailio -m 512'. Program terminated with signal 11, Segmentation fault. #0 0x7f8a11d55fa7 in unref_dlg (dlg=0x7f89f7e07470, cnt=1) at dlg_hash.c:474 474 d_entry = &(d_table->entries[dlg->h_entry]); Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-5.fc11.x86_64 db4-4.7.25-11.fc11.x86_64 e2fsprogs-libs-1.41.9-2.fc11.x86_64 elfutils-libelf-0.147-1.fc11.x86_64 glibc-2.10.2-1.x86_64 keyutils-libs-1.2-5.fc11.x86_64 krb5-libs-1.6.3-31.fc11.x86_64 libacl-2.2.49-3.fc11.x86_64 libattr-2.4.43-3.fc11.x86_64 libcap-2.16-4.fc11.1.x86_64 libconfuse-2.6-2.fc11.x86_64 libgcc-4.4.1-2.fc11.x86_64 libselinux-2.0.80-1.fc11.x86_64 lm_sensors-3.1.0-1.fc11.x86_64 lua-5.1.4-3.fc11.x86_64 mysql-libs-5.1.46-1.fc11.x86_64 net-snmp-libs-5.4.2.1-13.fc11.x86_64 nspr-devel-4.8.4-1.3.fc11.x86_64 nss-devel-3.12.6-1.2.fc11.x86_64 nss-softokn-freebl-3.12.6-1.2.fc11.x86_64 openssl-0.9.8n-1.fc11.x86_64 pcre-7.8-2.fc11.x86_64 perl-libs-5.10.0-82.fc11.x86_64 popt-1.13-5.fc11.x86_64 radiusclient-ng-0.5.6-4.fc11.x86_64 rpm-libs-4.7.2-1.fc11.x86_64 tcp_wrappers-libs-7.6-55.fc11.x86_64 xz-libs-4.999.9-0.1.beta.20091007git.fc11.x86_64 zlib-1.2.3-22.fc11.x86_64 (gdb) bt full #0 0x7f8a11d55fa7 in unref_dlg (dlg=0x7f89f7e07470, cnt=1) at dlg_hash.c:474 d_entry = 0x0 __FUNCTION__ = "unref_dlg" #1 0x7f8a11d5180f in unref_dlg_from_cb (t=0x7f89f7d9c660, type=4096, param=0x7f8a1836a6e0) at dlg_handlers.c:622 dlg = 0x7f89f7e07470 #2 0x7f8a18138ea3 in run_trans_callbacks (type=4096, trans=0x7f89f7d9c660, req=0x0, rpl=0x0, code=0) at t_hooks.c:240 cbp = 0x7f89f7dc30e8 backup = 0x71a9d0 trans_backup = 0x __FUNCTION__ = "run_trans_callbacks" #3 0x7f8a181273cc in free_cell (dead_cell=0x7f89f7d9c660) at h_table.c:132 b = 0x0 i = 1 rpl = 0x0 tt = 0x0 foo = 0x7fff4282f190 p = 0x7f89f7d3b068 #4 0x7f8a18127bb6 in free_hash_table () at h_table.c:345 p_cell = 0x7f89f7d9c660 tmp_cell = 0x0 i = 4075 #5 0x7f8a181342a4 in tm_shutdown () at t_funcs.c:109 __FUNCTION__ = "tm_shutdown" #6 0x004529f6 in destroy_modules () at sr_module.c:321 t = 0x7349d0 foo = 0x734910 __FUNCTION__ = "destroy_modules" #7 0x0041f6b4 in cleanup (show_status=1) at main.c:331 No locals. #8 0x00420597 in handle_sigs () at main.c:517 chld = 0 chld_status = 134 i = 12 do_exit = 1 ---Type to continue, or q to quit--- shutdown_time = 60 __FUNCTION__ = "handle_sigs" #9 0x004217b5 in main_loop () at main.c:859 chd_rank = 12 i = 4 pid = 21442 si = 0x0 __FUNCTION__ = "main_loop" #10 0x00423410 in main (argc=3, argv=0x7fff4282f498) at main.c:1321 cfg_log_stderr = 0 cfg_stream = 0x1fe1010 c = -1 r = 0 tmp_len = 0 port = 0 proto = 4910128 ret = -1 rfd = 4 tmp = 0x7fff4282ff8a "" options = 0x4b77e0 "f:cCm:b:l:n:N:rRvdDFETSVhw:t:u:g:P:G:W:" rand_source = 0x4b7d9c "/dev/urandom" seed = 3628387751 __FUNCTION__ = "main" (gdb) (gdb) quit ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Issue with avp
could someone help me on this please ?
I have been trying to load rpid while loading credentials.
modparam("auth_db", "load_credentials", "$avp(i:123)=rpid")
Now, I am trying to do a check in my routing logic.
xlog("L_NOTICE","The avp is :$avp(i:123)"); (I dont get the value here
either, i can't see the value when i do avp_print()
if($avp(i:123)<5)
{
sl_send_reply("408","Message Here");
}
I dont get the value of avp at that place. And this is after successful
www/proxy_authenticate()
Thank you
Amit
On 2/10/2011 11:46 AM, Amit Nepal wrote:
Yes it is after successful www/proxy_authenticate()
Thank You
Amit Nepal
Systems Administrator
Phoenix Internet
Phone: 602-385-0731
602-234-0917#112
http://www.phoenixinternet.net
On 2/9/2011 11:54 PM, Daniel-Constantin Mierla wrote:
Hello,
On 2/9/11 10:35 PM, Amit Nepal wrote:
Hi,
I have been trying to load rpid while loading credentials.
modparam("auth_db", "load_credentials", "$avp(i:123)=rpid")
Now, I am trying to do a check in my routing logic.
xlog("L_NOTICE","The avp is :$avp(i:123)"); (I dont get the value
here either, i can't see the value when i do avp_print()
if($avp(i:123)<5)
{
sl_send_reply("408","Message Here");
}
I dont get the value of avp at that place. Any guidance please.
Is this piece of config after a successful www/proxy_authenticate()?
Cheers,
Daniel
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] CORE postgres module
Hi, During my tests with kamailio 1.5.0 a core is generated when postgres is disconnected and I try register a user or make a call in kamailio. Analising the module postgres source code I notice that core is generated by the PQescapeStringConn located in db_postgres_val2str function. Someone know why this core is generated? Best Regards ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio 1.5.5 crashes continue
It's Cenos VM under Xen on HP Proliant. On the neighbor VM Propetary Softswitch on java. Nothing more. I relocate The rest VM-s to other servers 1.3.4 was on ordinary computer: [root@ipshka ~]# uptime 18:53:37 up 742 days, 6:21, 1 user, load average: 0.00, 0.00, 0.00 On 02/14/2011 06:39 PM, Henning Westerholt wrote: On Monday 14 February 2011, Andrew O. Zhukov wrote: It's look like 1.5.5 much less stable then 1.3.4 7 crashes on this weekend [..] Hi Andrew, this is really unusual and of course bad, so far in our experience the 1.5 series is really stable. Also strange is that you see a signal 6 - this is SIGABRT. Otherwise the machine runs stable so far, i.e. no memory problems or crashes also in other daemons or something like this? Cheers, Henning ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio 1.5.5 crashes continue
On Monday 14 February 2011, Andrew O. Zhukov wrote: > It's look like 1.5.5 much less stable then 1.3.4 > > > 7 crashes on this weekend > [..] Hi Andrew, this is really unusual and of course bad, so far in our experience the 1.5 series is really stable. Also strange is that you see a signal 6 - this is SIGABRT. Otherwise the machine runs stable so far, i.e. no memory problems or crashes also in other daemons or something like this? Cheers, Henning ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio and MySQL licensing question
Am 14.02.2011 17:17, schrieb Siddhardha Garige: > hello all, > > I have a question regarding MySQL licensing. > > > > We configured kamailio to work in edge proxy mode with drive-by > registration to support our network architecture. One of our clients is > interested in conducting some trails with us and we are setting up a > test network at client's facility. As a part of this process we will be > installing our custom kamailio on their servers with MySQL. We are not > charging our client for kamailio and mysql implementation since they > both are open source implementations. But we will be charging them for > our time at clients facility. First, GPL license does not have any restrictions on charging. So, the question is not if you charge them or not. The question is: if you give them binary code, you have to give them (when they ask you) also the source code. Thus, if you have made changes to the code you have to give them also the changes. > Are we violating any MySQL license policies by installing our custom kamailio > with MySQL for our client? Mysql client libraries are by default GPL (unless you buy a comemrcial license). But as most of Kamailio is GPL too, I think you just have to obey the GPL license. regards klaus ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] kamailio and MySQL licensing question
hello all, I have a question regarding MySQL licensing. We configured kamailio to work in edge proxy mode with drive-by registration to support our network architecture. One of our clients is interested in conducting some trails with us and we are setting up a test network at client's facility. As a part of this process we will be installing our custom kamailio on their servers with MySQL. We are not charging our client for kamailio and mysql implementation since they both are open source implementations. But we will be charging them for our time at clients facility. Are we violating any MySQL license policies by installing our custom kamailio with MySQL for our client? thanks Sid "May the light be with you." __ Siddhardha Garige www.luminepixels.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 1.5.4 and beyond - mhomed issue under Linux
On 02/11/2011 09:14 PM, Sean O'Donnell wrote: Hi all, Hello Sean, I checked the GIT repository and noticed that there was a patch in forward.c for this issue. Looks like it was done 11/4/2010. Two questions: 1) Is there any reason that patch didn't make it into Kamailio 3.1.2 ? Indeed, there is no reason. Actually I have cherry-picked the patches into the 3.1 branch (commit_notice 3.1 3ec1e9 and 9ef0a1e). Thanks for noticing. 2) Any reason I shouldn't apply that patck to my 1.5.4 release? The patch was already applied to the svn 1.5 branch (don't know if the latest 1.5.5 tar ball has it) but you can install it from svn and you can find it there (commit 6050) Cheers Marius Thanks, Sean O'Donnell Senior Engineer uReach Technologies, Inc. On Thu, 10 Feb 2011, Sean O'Donnell (skodonn...@ureach.com) wrote: Hi all, I just started deploying Kamailio release 1.5.4, and I think there's an issue with how Kamailio identifies an outgoing interface when mhomed is enabled under Linux. I use Kamailio as a call distributor/proxy between a soft-switch/SBC and a voicemail platform. It runs on a CentOS 5.3 (Linux 2.6 kernel) host with two network interfaces and is configured such that it listens on both interfaces. One interface (public interface) handles traffic with the SBC, the other (private interface) handles with the VM platform. The 'mhomed' option is enabled. After upgrading from 1.5.3 to 1.5.4, I started noticing problems with UDP packets coming out of the public interface. After looking at some ngrep captures on that interface, I noticed that some packets had the source IP address of the private interface and also had Record-Route and Via headers for the private interface only - no headers for the public interface were there. Usually when I see the wrong source IP in a UDP packet, it's an issue with how routes are set up on the host. However, I had our network engineer double check them, and they seem fine (no ambiguous routes). The fact that I captured these messages on the public interface also indicates to me that the kernel is routing the message correctly. The missing Record-Route and Via for the public interface, however, lead me to believe that the proxy didn't correctly identify the outgoing interface in the first place. After looking at the ChangeLog for 1.5.4, I noticed that the some new logic was put in to improve performance when mhomed is enabled (r5971) in forward.c, and I think this is the issue. As I understand it, prior to 1.5.4, when mhomed was enabled, Kamailio determined the outgoing interface by creating a temporary UDP socket, invoking connect() on the socket with the packet destination, then checking the source IP of the socket that the kernel assigned using getsockname(). After the source address was determined, the temp socket was closed closed. As of 1.5.4, this was modified to reuse the temporary socket and just re-invoking connect() with a new destination address. The problem with the enhancement is that Linux (again, at least in the 2.6 kernels I'm using) doesn't seem to rebind a new source address to the socket when connect() is called more than once on a UDP socket. Instead, it keeps the original one, and thus the wrong interface is assumed. I wrote a small program to confirm this - basically creates a UDP socket, calls connect()/getsockname() multiple times using different destination addresses. I ran it on several 2.6 kernels, including Centos4.x and Centos5. The result was always that the source address of the socket wasn't changed after the first connect(), regardless of the destination address. The only way I could get it work as required was to first do a connect() using a zero'd out AF_UNSPEC address before doing the connect() to the remote address. I also ran it on Solaris and it worked. Go figure. I've downloaded the latest stable release (3.1.2) but I think the issue is still there, and I don't see anything in the user groups that addresses this. Any help would be appreciated. Thanks, Sean ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
