Hi,
We have this approach for arrayable PVs (e.g. AVPs, XAVPs):
$(avp(var)[*]) = $null;
This defines the PV, but sets its value to null. I haven't tested, but I
would assume, in the case of an AVP, that this would cause it to fail
defined $avp(var)
is_avp_set("$avp(var)")
But, I see there is also in the 'pv' module now a function pv_unset(), i.e.
pv_unset("$avp(var)");
pv_unset("$var(foo)");
I assume this actually deletes the variable itself from the namespace,
instead of assigning it an undefined value.
Are there pros and cons to using one or the other to mass-reset
variables relevant to call processing at the beginning of route script?
Thanks,
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Hello Everyone,
Thank you for reply,
On client I configured user @ domain.org and proxy point to kamailio
Here 1 debug where on client after doamin.org port is left configured to 5061
http://fpaste.org/188145/44047614/
Second debug where port set to 0 and kamailio tries resolve and crashed
http://fpaste.org/188148/24440702/
Here config file
http://fpaste.org/188149/24440841/
Thank you,
Slava.
From: "Olle E. Johansson" <oej(a)edvina.net>
To: "Daniel Constantin Mierla" <miconda(a)gmail.com>, "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Thursday, February 19, 2015 4:34:04 AM
Subject: Re: [SR-Users] kamailio asterisk
We also need to check the core file from the crash.
/O
On 19 Feb 2015, at 09:30, Daniel-Constantin Mierla < miconda(a)gmail.com > wrote:
Hello,
can you send the REGISTER request received by kamailio and your config to me?
As you receive it over TLS, you can get the register by adding the next line in kamailio.cfg at the beginning of request_route:
xlog("received request: [[$mb]]\n");
I will like to double check if the issue is still present.
You should upgrade to 4.2.3, because it is the latest stable, you have 4.2.1 and there were many fixes meanwhile.
If you preserve sips as uri schema, then you force tls further for forwarding. You should change that to sip:domain ...
Cheers,
Daniel
On 18/02/15 00:37, Slava Bendersky wrote:
BQ_BEGIN
Hello Everyone,
I have standard case where kamailio play role of proxy for asterisk servers.
Kamailio configured use TLS transport on public side and on private side UDP 5060.
When client (SIP soft phone) connect to TLS socket everything goes well until kamailio trying forward request. Kamailio tries DNS resolve tls transport srv records instead of udp then it just crashed when no tls configured on private side of kamailio.
Do I need manually fix sips in URI ? Or some different miss configuration ?
[root@canlvprx01 kamailio]# rpm -qa | grep kamail
kamailio-carrierroute-4.2.1-4.2.fc21.x86_64
kamailio-mysql-4.2.1-4.2.fc21.x86_64
kamailio-outbound-4.2.1-4.2.fc21.x86_64
kamailio-4.2.1-4.2.fc21.x86_64
kamailio-tls-4.2.1-4.2.fc21.x86_64
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [parser/msg_parser.c:625]: parse_msg(): method: <REGISTER>
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri: <sips:domain.org> ---> Client come with TLS transport
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0>
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==12 && [ domain.org ] == [ 10.18.130.46 ]
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==11 && [ domain.org ] == [67.34.12.56]
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5081 (advertise 0) matches port 5060
Feb 17 11:13:49 canlvprx 01 kernel: [4130713.518667] kamailio[22484]: segfault at 88 ip 0000000 0004bd30c sp 00007fffa2f73a20 error 4 in kamailio[400000+3b8000]
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [forward.c:448]: check_self(): check_self: host != me
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[SIPOUT] c=[/etc/kamailio/kamailio-asterisk.cfg] l=850 a=25 n=append_hf
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[SIPOUT] c=[/etc/kamailio/kamailio-asterisk.cfg] l=851 a=5 n=route
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=16 n=if
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=563 a=25 n=is_method
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=16 n=if
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=25 n=is_method
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=574 a=16 n=if
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=24 n=t_relay
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=1 , global msg id=1 , T on entrance=(nil)
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=48550, isACK=0
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: trans=0x7f598a9ced40, callback type 1, id 0 entered
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: trans=0x7f598a9ced40, callback type 1, id 0 entered
Feb 17 11:13:49 canlvprx 01 kernel: kamailio[22484]: segfault at 88 ip 00000000004bd30c sp 00007 fffa2f73a20 error 4 in kamailio[400000+3b8000]
Feb 17 11:13: 49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [md5utils.c:67]: MD5St ringArray(): DEBUG: MD5 calculated: 0475e0d0dd9778e889618cb724403b4d
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:566]: _dns_hash_find(): dns_hash_find(_sips._ tcp.networklab.ca (24), 33), h=646
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [resolve.c:967]: get_record(): get_record: skipping 1 NS (p=0xa1f556, end=0xa1f588)
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [resolve.c:983]: get_record(): get_record: parsing 2 ARs (p=0xa1f568, end=0xa1f588)
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:1772]: dns_get_related(): dns_get_related(0x7f598a9e89b0 (_sips._ tcp.domain.org , 33), 33, *0x7f5995bd55e0) (0)
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: adding _sips._ tcp.domain.org (24) 33 (flags=0) at 646
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: adding camsgsrv02.domain.org (24) 1 (flags=0) at 967
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:566]: _dns_hash_find(): dns_hash_find( camsgsrv02.domain.org (24), 1), h=967
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [msg_translator.c:2871]: create_via_hf(): create_via_hf: id added: <;i=1>, rcv proto=3
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [tcp_main.c:1818]: tcp_send(): tcp_send: no open tcp connection found, opening new one
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 10.18.130.50
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 5061, type 3
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 3263:0:0, 2
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) WARNING: <core> [tcp_main.c:1221]: tcp_do_connect(): 10.18.130.50 :5061: could not find corresponding listening socket for 10.18.130.46 , using default...
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls [tls_server.c:184]: tls_complete_init(): Using TLS domain TLSc<default>
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake started
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [tcp_main.c:2697]: tcpconn_1st_send(): pending write on new connection 0x7f598a9d4678 (-1/129 bytes written)
Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> [tcp_main.c:3565]: handle_ser_child(): handle_ser_child: read response= 7f598a9d4678, 5, fd 31 from 11 (22480)
Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9daf00, 31, 2, 0x7f598a9d4678), fd_no=19
Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_funcs.c:394]: t_relay_to(): SER: new transaction fwd'ed
Thank you Slava.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
BQ_END
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi all
I need to check a given uri against dispatcher destination entries. I see that
it's possible in kamailio 4.2 using ds_is_from_list which allows "uri"
parameter but it's not available in version 3.3.
Moving to 4.x is not an option this time.
Any hints about how to check this? Raw sql + string comparation or something
more elegant out there?
thanks,
Jon
I've been running Kamailio 4.2.2/4.2.3 in a FreeBSD 10.1 jail for a few weeks, thanks to a recent port in the FreeBSD ports tree. However, it has been a bit unstable. It crashes randomly. It's hard to debug since it can go three days without crashing, and there is no obvious trigger.
I'm also running 4.1.0 on FreeBSD 8.3, compiled from source manually. It is rock solid for a long time now.
So, I have 2 theories:
1) My FreeBSd ports patch for ip_addr.h is wrong. I was having to define INADDR_LOOPBACK since compile would fail with 'undeclared identifier'. My patch was to define INADDR_LOOPBACK in ip_addr.h as a 'long' as such:
#define INADDR_LOOPBACK (long) 0x7F000001
However, it appears this should have been:
#define INADDR_LOOPBACK (unsigned long) 0x7F000001
The previous patch seemed to work, but could have caused the crashes I'm seeing.
2.) The NAT SIPPing feature defined with WITH_NATSIPPING is a new feature since 4.1.0. So my 4.1.0 installation does not use it. Now that I am using it on 4.2.3, I am getting this random crash. I suspect that the feature uses an ICMP ping at some stage. In FreeBSD jails, by default ping is not allowed (security feature). If you really need to ping then you need to explicitly allow raw sockets. So perhaps Kamailio doesn't know how to handle the "operation not permitted" and crashes.
I am going to test without NAT SIPping and see if it crashes. Although it's hard to test, since I have no trigger and it can be days between crashes.
** My question is: how do I force the ping behaviour in NAT SIPping feature? I need a trigger to further debug.
Output from /var/log/messages after crash:
Feb 19 05:39:56 sip /usr/local/sbin/kamailio[52610]: CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 24
Feb 19 05:39:56 sip /usr/local/sbin/kamailio[52578]: ALERT: <core> [main.c:784]: handle_sigs(): child process 52606 exited by a signal 6
Feb 19 05:39:56 sip /usr/local/sbin/kamailio[52578]: ALERT: <core> [main.c:787]: handle_sigs(): core was generated
Hi All
We have any issue with re invites coming from the carrier.
When a reinvite occurs, our softphone client gets the invite, sends a 100,
and then sends 200 ok. However the 200 ok does not have the softphones ip
in the record route. Since it's not in the record route the ack from the
carrier never makes it's way all the back to the softphone.
This causes the softphone to keep sending 200 oks since it never gets the
ack.
Eventually the softphone gets tired of sending 200 oks and sends a bye.
Is there any way that Kamailio can help me correct for this, or do we need
to have our clients use different softphones? If it has to be handled via
softphones is there even a softphone that can account for this?
Thanks for all your assistance in advance.
All the best.
Will Ferrer
Switchsoft
Hi Guys,
Using kamailio Version 4.1.4 on Centos 6.5 I have an issue when using cnxcc to control max call duration for all outbound calls.
In my configuration I set the following;
# -----Dialog params -----modparam("dialog", "dlg_flag", 4)modparam("cnxcc", "dlg_flag", 4)modparam("cnxcc", "credit_check_period", 1)
Then I look to set some parameters for outbound calls;
###########Set Max Call Duration for MT Call #############
$var(customer) = "MTPublic";$var(max_time) = $var(MTMaxCallDuration);xlog("L_INFO","For setting Call Duration we have ProfileID=$var(profileIDMD) and we have var(max_time)=$var(max_time)\n");cnxcc_set_max_time("$var(customer)", "$var(max_time)");xlog("L_INFO","Max Call duration set to $var(max_time) seconds\n");
Feb 20 14:20:26 voip01 /usr/sbin/kamailio[1950]: INFO: <script>: Max Call duration set to 600 secondsFeb 20 14:20:35 voip01 /usr/sbin/kamailio[1960]: ALERT: cnxcc [cnxcc_check.c:157]: check_calls_by_time(): [74d7c02e-33ae-1233-edba-005056a48754] call has exhausted its time. Breaking the loopFeb 20 14:20:35 voip01 /usr/sbin/kamailio[1960]: INFO: <script>: [74d7c02e-33ae-1233-edba-005056a48754]: call killed as Max Call Duration ExpiredFeb 20 14:20:35 voip01 /usr/sbin/kamailio[1960]: ERROR: cnxcc [cnxcc_mod.c:1068]: terminate_call(): Error executing dlg_end_dlg command. Return code was [404]
Now as you can see, as soon as the Called party answers, the cnxcc module drops the call stating that Max Call duration has expired, however it was set to 600 seconds.
If I restart kamailio this clears the issue and it works fine allowing calls to run up to 600 seconds.
Any help/comment on this would be great, is it just configuration related?
Thanks
Jon
Good morning,
I'm looking for someone who, according to my guidelines set kamailio and
connect the asterisk.
Kamailio to act as a proxy server to accept registrations sip and locate.
Pay for the correct configuration.
Please contact me with people interested.
Regards
Tom
