Yes, this is a sipcapture node. I'm listening on a switch port that is
set to mirror my VoIP traffic. I see all SIP UDP/TCP packets on the
mirror port and the Ethernet port of the host node. Just don't see any
TCP packets process in kamailio, debug 3. UDP packets are processed as
expected.
My config is using port mirror for the capture parameters:
modparam("sipcapture", "capture_on", 1)
modparam("sipcapture", "hep_capture_on", 0)
modparam("sipcapture", "raw_ipip_capture_on", 0)
modparam("sipcapture", "raw_moni_capture_on", 1)
modparam("sipcapture", "raw_sock_children", 4)
modparam("sipcapture", "raw_interface", "eth1")
modparam("sipcapture", "raw_socket_listen", "10.99.99.99:5060-5070")
modparam("sipcapture", "promiscious_on", 1)
modparam("sipcapture", "raw_moni_bpf_on", 1)
Is there a method I could diagnose if the SIP TCP Packets are getting
from the kernel network process and the kamailio process?
# ngrep -d eth1 -W byline host x.x.x.x | /var/run/kamailio/kamailio.pid
Or pipe to kamailio local unix socket?
I don't know, I'm just guessing.
Thanks.
JR
> Somehow is not clear for me how you have the configuration there ...
> before commenting further, this needs to be clarified.
>
> The node you presented the config is a sipcapture instance, right? What
> is sending traffic to it? Is another kamailio with siptrace module? Or
> the sipcature agent? Or you have a port mirroring in the router?
>
> Cheers,
> Daniel
>
>
> On 17/01/2017 16:37, JR Richardson wrote:
>>> On Mon, Jan 16, 2017 at 10:29:39AM -0600, JR Richardson wrote:
>>>> Yes, I'm familiar with the methods sipcapture uses, I don't use HEP,
>>>> using raw socket capture, I think this may be a sipcapture issue,
>>>> debuging kamailio shows normal startup and processing of UDP SIP
>>>> packets, but does not show any activity with TCP packets.
>>> I never used HOMER sofar but when I saw your first message my thoughts
>>> was that this can't work in a simple way since for TCP you need to
>>> complete a 4 way handshake before you can start to send data.
>>>
>> Interesting. Are you referring to handshaking on the network stack or
>> SIP TCP TLS handshaking? I guess I can see it two ways.
>>
>> 1) if your talking about TCP/IP handshake, even though the SIP packet
>> comes into the mirror port on the host node, the kernel processing the
>> TCP packet is not establishing a valid connection due to no TCP
>> handshake because its only a monitor port, no transmit back, then the
>> kernel network stack does not pass the SIP TCP packet to the kamailio
>> process for capture because it drops the packet due to no valid
>> handshake?
>>
>> 2) the kernel network stack is passing the SIP TCP packet to the
>> kamailio process, but since kamailio cannot handshake back it drops
>> the packet and does not process through the sipcapture module. This
>> kinda breaks the whole capture ability for homer with SIP TCP. Using
>> ngrep, I see all SIP TCP packets, invite -->, trying <--, session
>> progress <--, request timeout <--, ack -->, etc...
>>
>> So how would I diagnose if the network stack is the culprit? Debugging
>> kamailio is pretty straight forward, setup and listening for SIP TCP,
>> but never see any processing of any TCP packets.
>>
>> Thanks.
>>
>> JR
>
--
JR Richardson
Engineering for the Masses
Chasing the Azeotrope
Hello,
Kamailio SIP Server v4.4.5 stable release is out.
This is a maintenance release of the latest stable branch, 4.4, that
includes fixes since the release of v4.4.4. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v4.4.x. Deployments running previous v4.x.x
versions are strongly recommended to be upgraded to v4.4.5.
For more details about version 4.4.5 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2017/01/kamailio-v4-4-5-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello,
I am considering to release v4.4.5 with latest fixes from branch 4.4
later this week, on Wednesday or Thursday (Jan 19 or 20). As usual, if
anyone has fixes that were not backported yet, do it if you are a
developer or write to sr-dev to be sure it is not missed. Sumbit also
the new issues you are ware of and they are not on the bug tracker.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
Hi,
I am troubleshooting some strange call setup problems using an Edgewater
Networks SBC. A couple of Polycom phones sit behind the SBC and they
connect to a SIP Server in the cloud. The SBC is in passthrough mode.
What I see that I am not sure about is:
INVITE from SIP Server to SBC IP (no Record-Route header...so far no
surprise here)
INVITE from SBC to Phone (Record-Route header inserted by SBC but with
the IP of the SIP Server)
I do not think the SBC is supposed to add a Record-Route header with the
IP of the remote SIP Server. I think It should only be allowed to add
Record-Route headers with its own IP. Does that sound right?
The RFC lists the usage as:
"20.30 Record-Route
The Record-Route header field is inserted by proxies in a request to
force future requests in the dialog to be routed through the proxy."
It says nothing about being able to arbitrarily force future requests to
go through a remote IP.
Please advise.
Thanks,
--
Technical Support
> On Mon, Jan 16, 2017 at 10:29:39AM -0600, JR Richardson wrote:
>> Yes, I'm familiar with the methods sipcapture uses, I don't use HEP,
>> using raw socket capture, I think this may be a sipcapture issue,
>> debuging kamailio shows normal startup and processing of UDP SIP
>> packets, but does not show any activity with TCP packets.
>
> I never used HOMER sofar but when I saw your first message my thoughts
> was that this can't work in a simple way since for TCP you need to
> complete a 4 way handshake before you can start to send data.
>
Interesting. Are you referring to handshaking on the network stack or
SIP TCP TLS handshaking? I guess I can see it two ways.
1) if your talking about TCP/IP handshake, even though the SIP packet
comes into the mirror port on the host node, the kernel processing the
TCP packet is not establishing a valid connection due to no TCP
handshake because its only a monitor port, no transmit back, then the
kernel network stack does not pass the SIP TCP packet to the kamailio
process for capture because it drops the packet due to no valid
handshake?
2) the kernel network stack is passing the SIP TCP packet to the
kamailio process, but since kamailio cannot handshake back it drops
the packet and does not process through the sipcapture module. This
kinda breaks the whole capture ability for homer with SIP TCP. Using
ngrep, I see all SIP TCP packets, invite -->, trying <--, session
progress <--, request timeout <--, ack -->, etc...
So how would I diagnose if the network stack is the culprit? Debugging
kamailio is pretty straight forward, setup and listening for SIP TCP,
but never see any processing of any TCP packets.
Thanks.
JR
--
JR Richardson
Engineering for the Masses
Chasing the Azeotrope
I'm involved in setting up a Kamailio instance and was hoping to make use of the auth_ephemeral module for authentication. But the module documentation doesn't quite make clear how exactly the module is to be employed or the web service set up. Does anyone have a working example?
Regards,
Hemanshu Vadehra
hemanshu.v(a)directi.com
Hello,
we've noticed that the usrloc module does not "sync" all the records from
memory into the database.
I use a bash script to generate in-memory AoRs (
http://paste.debian.net/plain/908521)
then i perform
kamcmd ul.flush
and no records are inserted.
We have tried various usrloc parameters but none seem to work
Here is our basic setup
# ----- usrloc params -----
modparam("usrloc", "db_url", DBURL)
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "use_domain", 1)
modparam("usrloc", "timer_interval", 120)
modparam("usrloc", "timer_procs", 4)
We are using postgresql.
are we missing something?
Thanks
/V
Hello,
I'm trying LCR module and dont_strip_or_tag_flag parameter.
If I use this line in the module configuration:
modparam("lcr", "dont_strip_or_tag_flag", 10)
and then restart kamailio, i receive this error:
ERROR: <core> [modparam.c:141]: set_mod_param_regex(): parameter
<dont_strip_or_tag_flag> of type <2> not found in module <lcr>
I'm using 4.4.4 version
Any hint?
Thank you
Regards
Hey Daniel,
Yes, I'm familiar with the methods sipcapture uses, I don't use HEP,
using raw socket capture, I think this may be a sipcapture issue,
debuging kamailio shows normal startup and processing of UDP SIP
packets, but does not show any activity with TCP packets. I have
enabled/disabled the different capture methods and no TCP SIP packets
are processed. Also, I didn't mention before I'm testing on 2
different instances, one is a Homer 3.5 (Kamailio 4.1.2) and another
is Homer 5.0 (Kamailio 4.4.0). I'll post to the Homer list and see
what they say.
Thanks.
JR
> is it this about a sipcature node? If yes, then it receives the packets
> over HEP, meaning that is not going to the normal processing path.
> Kamailio detects it is not a SIP packet, executes some callbacks for
> non-sip packets registered by modules (in this case sipcapture). The
> module detecting it's a packet for it, can execute the request_route
> once it builds a local sip packet.
>
> To troubleshoot further, run with debug=3 in kamailio.cfg and see what
> you get in the logs.
>
> Cheers,
> Daniel
>
> On 13/01/2017 16:33, JR Richardson wrote:
>> Iptables is not blocking, but it was worth a check.
>>
>> Thanks.
>>
>> JR
>>
>>
>> I assume you have ruled out firewall? It's something that can nab even
>> experienced people:
>>
>> # iptables -Ln
>>
>> -- Alex
>>
>> On Thu, Jan 12, 2017 at 03:25:27PM -0600, JR Richardson wrote:
>>
>>> Hi All,
>>>
>>> Just enabled SIP TCP on a homer capture server, I can see the SIP TCP
>>> Sessions on the server with ngrep, just like all the UDP traffic. I
>>> have Kamailio listening on TCP ports but its not capturing any TCP
>>> traffic.
>>>
>>> kamailio.cfg:
>>>
>>> #disable_tcp=yes
>>> listen=tcp:10.99.99.99:5060 #monitor port
>>> listen=udp:10.99.99.99:5060 #monitor port
>>>
>>> loadmodule "pv.so"
>>> loadmodule "db_mysql.so"
>>> loadmodule "sipcapture.so"
>>> loadmodule "textops.so"
>>> loadmodule "rtimer.so"
>>> loadmodule "xlog.so"
>>> loadmodule "sqlops.so"
>>> loadmodule "htable.so"
>>> loadmodule "sl.so"
>>> loadmodule "siputils.so"
>>>
>>>
>>> modparam("sipcapture", "capture_on", 1)
>>> modparam("sipcapture", "hep_capture_on", 0)
>>> modparam("sipcapture", "raw_socket_listen", "10.99.99.99:5060-5070")
>>> modparam("sipcapture", "raw_interface", "eth1")
>>> modparam("sipcapture", "raw_ipip_capture_on", 0)
>>> modparam("sipcapture", "table_name", "sip_capture")
>>> modparam("sipcapture", "raw_sock_children", 4)
>>> modparam("sipcapture", "db_insert_mode", 0)
>>> modparam("sipcapture", "raw_moni_capture_on", 1)
>>> modparam("sipcapture", "promiscious_on", 1)
>>> modparam("sipcapture", "raw_moni_bpf_on", 1)
>>> modparam("sipcapture", "capture_node", "homer02")
>>> modparam("sipcapture", "authorization_column", "authorization")
>>>
>>>
>>> ## logging all INVITES top of the [route] block
>>> if (is_method("INVITE|REGISTER")) {
>>> xlog("L_INFO", "Received INVITE \"$fU\" to \"$rU\"
>>> from \"$si\"\n");
>>>
>>> Logging reports all SIP UDP traffic to logs fine, but no TCP traffic.
>>>
>>> root@homer02:~# netstat -al
>>> Active Internet connections (servers and established)
>>> Proto Recv-Q Send-Q Local Address Foreign Address State
>>> tcp 0 0 homer02.me.com:sip *:* LISTEN
>>>
>>>
>>> I don't think this is a homer issue because logging invites is prior
>>> to any homer processing. I'm thinking this is something simple I'm
>>> overlooking, any help is much appreciated.
>>>
