Homer SIP capture integration
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
Hi, 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://code.google.com/p/homer/source/browse/?name=webhomer_3.6 I did the trick with disable the kamailio capture node log-level to zero. 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. But Alexandr will fix that in future. Btw, cool stuff is sipgrep 2.0 rewritten in C from Alexandr. 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*
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:
Hi,
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://code.google.com/p/homer/source/browse/?name=webhomer_3.6
I did the trick with disable the kamailio capture node log-level to zero.
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. But Alexandr will fix that in future.
Btw, cool stuff is sipgrep 2.0 rewritten in C from Alexandr. https://github.com/adubovikov/sipgrep
2014-04-04 17:06 GMT+02:00 Peter Steinbach <lists@telefaks.de <mailto: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 <https://groups.google.com/forum/#%21topic/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 <tel:06081688533>" <sip:06081688533@192.168.178.204 <mailto:sip%3A06081688533@192.168.178.204>>;tag=as190e467c#015#012To: <sip:4488329@192.168.178.220:5090 <http://sip:4488329@192.168.178.220:5090>>;tag=1D8c28jZaF72r#015#012Call-ID: 17888b4f3812b7686fbaf0ca380be672@192.168.178.204#015#012CSeq <http://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 <mailto:sip%3A4488329@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 <mailto:lists> (att) telefaks.de <http://telefaks.de> Internet: www.telefaks.de <http://www.telefaks.de>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto: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 <mailto: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
We got it solved. Just for the records: By migrating from Debian to CentOS we detected that under CentOS, Kamailio expects the kamailio.cfg in /usr/local/etc/kamailio/kamailio.cfg instead of /etc/kamailio/kamailio.cfg in Debian. That solved the problem. In our case, Kamailio started with the default Kamailio config from /usr/local/etc/kamailio/ and treated the HEP messages as plain SIP messages. That was the reason for the error messages in the log. Btw: Freeswitch currently submits HEP V1 messages with a 16 byte header. Best regards Peter On 04/08/14 12:54, Peter Steinbach wrote:
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:
Hi,
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://code.google.com/p/homer/source/browse/?name=webhomer_3.6
I did the trick with disable the kamailio capture node log-level to zero.
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. But Alexandr will fix that in future.
Btw, cool stuff is sipgrep 2.0 rewritten in C from Alexandr. https://github.com/adubovikov/sipgrep
2014-04-04 17:06 GMT+02:00 Peter Steinbach <lists@telefaks.de <mailto: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 <https://groups.google.com/forum/#%21topic/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 <tel:06081688533>" <sip:06081688533@192.168.178.204 <mailto:sip%3A06081688533@192.168.178.204>>;tag=as190e467c#015#012To: <sip:4488329@192.168.178.220:5090 <http://sip:4488329@192.168.178.220:5090>>;tag=1D8c28jZaF72r#015#012Call-ID: 17888b4f3812b7686fbaf0ca380be672@192.168.178.204#015#012CSeq <http://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 <mailto:sip%3A4488329@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 <mailto:lists> (att) telefaks.de <http://telefaks.de> Internet: www.telefaks.de <http://www.telefaks.de>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto: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 <mailto: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
participants (2)
-
Karsten Horsmann
-
Peter Steinbach