Hello Karsten,
thanks for our input.
In my case, Kamailio does not even put the messages into the database, so disabling log will not help, I am sure.
But my main question is: Are the additional bytes in front of the SIP message (see below) valid or not? In that case it may be easy to just patch the kamailio and drop the bytes in front of the message
Best regards
Peter
On 04/07/14 15:38, Karsten Horsmann wrote:
Btw, cool stuff is sipgrep 2.0 rewritten in C from Alexandr.But Alexandr will fix that in future.Also, there is a known bug in FreeSWITCH, that webrtc stuff is not correctly send via HEP, you see only on call-leg in that behavoir.I did the trick with disable the kamailio capture node log-level to zero.https://code.google.com/p/homer/source/browse/?name=webhomer_3.6Hi,yes i was testing homer 3.5 dev.
But since the kamailio world 2014 (which was last week in berlin) homer 3.6 is on the road in dev tree
https://github.com/adubovikov/sipgrep
2014-04-04 17:06 GMT+02:00 Peter Steinbach <lists@telefaks.de>:
Hello,
I was following http://code.google.com/p/homer/wiki/HOWTO#Capture_Agent
to have "Homer Sip capture" capturing an displaying a SIP Packets from
freeswitch.
This worked quite well on a Debian based system. But now we migrated it
to Centos 6 and it does not work anymore, although we used the identical
kamailio source code base. I think the underlying xml parser libs
somehow work differently on Centos.
What is puzzling me is the following
Apr 4 10:33:12 homer2centos /usr/local/sbin/kamailio[20698]: ERROR:
<core> [parser/msg_parser.c:705]: parse_msg(): ERROR: parse_msg:
message=<#001#020#002#021#023a#023aaaaaaaSIP/2.0 480 Temporarily
You can see that in front of the SIP message coming from freeswitch
there are some additional chars "#001#020#002#021#023a#023aaaaaaa". And
by wiresharking the SIP packages, Freeswitch in fact preceedes the SIP
message it sends to homer with these additional bytes.
Using a Debian based Kamailio this does not cause problems on the
Kamailio/Homer side, buit on Centos it does.
So my question is: Is this the right behaviour of Freeswitch when
forking the SIP message to the capture server?
In https://groups.google.com/forum/#!topic/homer-discuss/KhBF0Dy44SU I
found the following
>The problem was found: freeswitch duplicate all packets on SIP port
including empty "ping" messages.
>with mobile regards,
>Alexandr
Although I do not really understand the part "including empty ping
messages": Is there a way to suppress these ping messages?
Here is a complete error message:
Apr 4 10:33:12 homer2centos /usr/local/sbin/kamailio[20698]: INFO:
<core> [parser/parse_fline.c:229]: parse_first_line():
ERROR:parse_first_line: bad request first line
Apr 4 10:33:12 homer2centos /usr/local/sbin/kamailio[20698]: INFO:
<core> [parser/parse_fline.c:231]: parse_first_line(): ERROR: at line 0
char 39:
Apr 4 10:33:12 homer2centos /usr/local/sbin/kamailio[20698]: INFO:
<core> [parser/parse_fline.c:237]: parse_first_line(): ERROR: parsed so
far: #001#020#002#021#023a#023aaaaaaaSIP/2.0 480 Temporarily
Apr 4 10:33:12 homer2centos /usr/local/sbin/kamailio[20698]: INFO:
<core> [parser/parse_fline.c:242]: parse_first_line():
ERROR:parse_first_line: bad message
Apr 4 10:33:12 homer2centos /usr/local/sbin/kamailio[20698]: ERROR:
<core> [parser/msg_parser.c:705]: parse_msg(): ERROR: parse_msg:
message=<#001#020#002#021#023a#023aaaaaaaSIP/2.0 480 Temporarily
Unavailable#015#012Via: SIP/2.0/UDP
192.168.178.204:5060;branch=z9hG4bK6569ec1b;rport=5060#015#012Max-Forwards:
70#015#012From: "06081688533"
<sip:06081688533@192.168.178.204>;tag=as190e467c#015#012To:
<sip:4488329@192.168.178.220:5090>;tag=1D8c28jZaF72r#015#012Call-ID:
17888b4f3812b7686fbaf0ca380be672@192.168.178.204#015#012CSeq: 102
INVITE#015#012User-Agent:
FreeSWITCH-mod_sofia/1.5.11b+git~20140305T111532Z~783a4083ed~64bit#015#012Accept:
application/sdp#015#012Allow: INVITE, ACK, BYE, CANCEL, OPTIONS,
MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY#015#012Supported: timer,
path, replaces#015#012Allow-Events: talk, hold, conference,
refer#015#012Reason:
Q.850;cause=16;text="NORMAL_CLEARING"#015#012Content-Length:
0#015#012Remote-Party-ID: "4488329"
<sip:4488329@192.168.178.220>;party=calling;privacy=off;screen=no#015#012#015#012>
Apr 4 10:33:12 homer2centos /usr/local/sbin/kamailio[20698]: ERROR:
<core> [receive.c:146]: receive_msg(): ERROR: receive_msg: parse_msg failed
--
With kind regards
Peter Steinbach
Telefaks Services GmbH
mailto:lists (att) telefaks.de
Internet: www.telefaks.de
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
--
Mit freundlichen Grüßen
*Karsten Horsmann*
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- With kind regards Peter Steinbach Telefaks Services GmbH mailto:lists (att) telefaks.de Internet: www.telefaks.de
-- With kind regards Peter Steinbach Telefaks Services GmbH mailto:lists (att) telefaks.de Internet: www.telefaks.de