From: Charles Chance <charles.chance(a)sipcentric.com>
To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List" <sr-users(a)lists.sip-router.org>
Subject: Re: [SR-Users] dialog list query
Message-ID:
Charles hi,
>What db_mode are you using for dialog module?
Mode 5. I Don't need to persist the dialog state so means table maintained
in memory and not flushed to disk until shutdown but I can access it
through normal avp_db_query right?
>Are the entries in the db if you check manually?
If I do sercmd dlg.dlg_list I see the call fine including callid etc.
>Are you able to fetch other data using avp_db_query?
Yes lots of queries to non dialog tables working fine.
>And do you see any errors in the log?
No logs show query happening fine and returning Null.
Thanks
John
hello, I got the same issue. my sip device getting ok from kamailio, but
asterisk reply 401.
but.
this is my config: http://pastebin.com/jGCak01E
and I changed regfwd route to
$du = "sip:50.0.0.10:5060;transport=udp";
forward();
and now I see this in logs:
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/msg_parser.c:633]: parse_msg(): SIP Reply (status):
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/msg_parser.c:635]: parse_msg(): version: <SIP/2.0>
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/msg_parser.c:637]: parse_msg(): status: <200>
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/msg_parser.c:639]: parse_msg(): reason: <OK>
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/parse_via.c:1284]: parse_via_param(): Found param type 232,
<branch> = <0>; state=16
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/parse_via.c:2672]: parse_via(): end of header reached, state=5
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found,
flags=2
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the
first via
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[receive.c:152]: receive_msg(): After parse_msg...
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: tm
[t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg: msg id=25 global
id=24 T start=(nil)
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param:
tag=006cfccc318be31188fc19977b3a5651
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/parse_addr_spec.c:885]: parse_addr_spec(): end of header reached,
state=29
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To>
[63]; uri=[sip:77.37.241.151:5060]
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [<sip:
77.37.241.151:5060>]
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <1>
<OPTIONS>
*Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: tm
[t_lookup.c:1045]: t_reply_matching(): DEBUG: t_reply_matching: failure to
match a transaction*
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: tm
[t_lookup.c:1140]: t_check_msg(): DEBUG: t_check_msg: msg id=25 global
id=25 T end=(nil)
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body :
content_length=0
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[parser/msg_parser.c:106]: get_hdr_field(): found end of header
*Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[forward.c:784]: do_forward_reply(): reply cannot be forwarded - no 2nd via*
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying
list (nil)
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying
list (nil)
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying
list (nil)
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying
list (nil)
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying
list (nil)
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying
list (nil)
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil)
Feb 3 15:13:38 kamaz /usr/sbin/kamailio[14502]: DEBUG: <core>
[receive.c:296]: receive_msg(): receive_msg: cleaning up
any ideas?
and show me ur conf please.
--
Hi All,
I'm running into an issue, I'm not sure whether any of you seen this
yourselves and resolved it. Please share some pointers. My network is:
clients <--> Public IP(Kamailio/RTPProxy)10.1.128.11 <--> 10.1.128.34
(Freeswitch)
The 200 OK response from Freeswitch (on the way back from called party to
caller) to Kamailio is shown below. Notice the Contact header URI host part
contains Freeswitch Private IP (10.1.128.34). Kamailio suppose to change
that to Public IP before forwarding the 200 OK (copied below) to Caller in
public domain. But, it's not. As a result, ACK from Caller is not reaching
back to Kamailio.
How did you or anybody out there using Kamailio resolve this problem? If
needed, I can copy/paste my kamailio.cfg.
--
yours respectfully, Alexander Vasin.
8 926 1437200
icq: 9906064
Dear list,
I'm having a problem.
I have an SBC server with two network interfaces, one external IP
(X.X.248.194) and other internal IP (X.X.248.21). Messages are sent to the
proxy sip server through internal ip with this configuration:
route [sip-serverr] {
rewritehostport ("ip_sip_proxy: 5060");
force_send_socket (X.X.248.21: 5060);
t_relay ();
exit;
}
When a UA sends an INVITE to the SBC, the responses (back) to UA are being
sent with the correct external source IP (X.X.248.194) but if there are
retransmissions of these responses, after 6 seconds, the source IP changes
to the internal ip (X.X.248.21)
Does anyone from the list know how I can solve this?
Attached picture of wireshark capture for better understanding.
--
Diego Alejandro Ozuna
Hi all,
we all enjoy our FAIL2BAN and snippets of our Kamailio config when we see it successfully fight off the "friendly-scanner", and multiple futile attempts to fool our systems. But it got me thinking…
What is a sufficient level of security on our Kamailio machinery… ? Are we all just doing whatever, or is the nature of the beast, that every setup is different?
Eventually while having a beer, we will end up in the discussion Kamailio is as good (and even much better) as most of the commercially available SBCs. But, imho, that all depends on the configuration.
There are a few good reads available, and on the security front I personally love Pike, Topoh, Dnssec, Htable and recently I think I'm doing rather clever stuff with CNXCC… And I do feel comfortable on my setups, them won't be hacked…
But do we have a-sort -of stake in the ground example configuration which we can consider as being more than sufficiently secure? Some config where we can tick off all the known security risks for SIP (as chapter 26 of rfc3261 gives a state of the art back in 2002) Or would that be a nice idea for a micro project?
Grtz,
Davy
Hi all
I need a solution to get the used scan_prefix in carrierroute module.
We have different carriers for our destinations, sometimes split up 50%/50% or other splittings - all routes with failure routes.
Now if one destination is not reachable, then I would like to get this information and reroute to another carrier.
As we use the carrierroute module, we use the "description" to get the carriername (for billing purposes).
Is there a solution to get the used scan_prefix from the carrierroute module?
Regards,
Oli
Hi Alex,
We set the hash size to 32 MB and found that the hash size is not the same
as configured one. At the max it was taking 64KB.
Regards,
Shankar
Date: Mon, 03 Feb 2014 00:27:29 -0500
From: Alex Balashov <abalashov(a)evaristesys.com>
To: sr-users(a)lists.sip-router.org
Subject: Re: [SR-Users] Regd. MAX_LDG_LOCKS
Message-ID: <52EF28C1.5010204(a)evaristesys.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 02/03/2014 12:22 AM, Shankar wrote:
> Also we found that in ?dialog.c? the variable dlg_hash_size should be
> ?unsigned int?. Hope this will be taken care in next release of Kamailio.
How did you arrive at that conclusion?
--
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/
From: Shankar [mailto:shankar.rk@plintron.com]
Sent: Monday, February 03, 2014 10:53 AM
To: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users
Mailing List'
Subject: Regd. MAX_LDG_LOCKS
Hello,
Can anyone brief about MAX_LDG_LOCKS in dlg_hash.c?
Should I increase the value of MAX_LDG_LOCKS (hardcoded to 2048) if the hash
size is increased?
Also we found that in 'dialog.c' the variable dlg_hash_size should be
'unsigned int'. Hope this will be taken care in next release of Kamailio.
Regards,
Shankar
On 02/03/2014 12:22 AM, Shankar wrote:
> Also we found that in ‘dialog.c’ the variable dlg_hash_size should be
> ‘unsigned int’. Hope this will be taken care in next release of Kamailio.
How did you arrive at that conclusion?
--
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,
Can anyone brief about MAX_LDG_LOCKS in dlg_hash.c?
Should I increase the value of MAX_LDG_LOCKS (hardcoded to 2048) if the hash
size is increased?
Also we found that in 'dialog.c' the variable dlg_hash_size should be
'unsigned int'. Hope this will be taken care in next release of Kamailio.
Regards,
Shankar