[Freeswitch-users] Homer SIP capture integration

Tue Apr 15 13:53:09 MSD 2014

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 at telefaks.de
>> <mailto:lists at 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 at 192.168.178.204
>>     <mailto:sip%3A06081688533 at 192.168.178.204>>;tag=as190e467c#015#012To:
>>     <sip:4488329 at 192.168.178.220:5090
>>     <http://sip:4488329@192.168.178.220:5090>>;tag=1D8c28jZaF72r#015#012Call-ID:
>>     17888b4f3812b7686fbaf0ca380be672 at 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 at 192.168.178.220
>>     <mailto:sip%3A4488329 at 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 at freeswitch.org <mailto:consulting at freeswitch.org>
>>     http://www.freeswitchsolutions.com
>>
>>     
>>     
>>
>>     Official FreeSWITCH Sites
>>     http://www.freeswitch.org
>>     http://wiki.freeswitch.org
>>     http://www.cluecon.com
>>
>>     FreeSWITCH-users mailing list
>>     FreeSWITCH-users at lists.freeswitch.org
>>     <mailto:FreeSWITCH-users at 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 at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140415/e4695854/attachment.html 