[SR-Users] Parser error when enabling siptrace with HEP functionality

Wed Jan 6 11:00:24 CET 2016

Thank you for patch.

I have applied patches from your commits
526fb4cdc2246284ecbd7de9ed65678da2dbe357 and
284c11ed16bdc5afcc9abf49c9f5c1749ce831e0
to kamailio 4.3.4 it was applied and build successfully.

There is no more errors in kamailio.log.

But Packet which is send by siptrace module to homer capture server is
send before topoh modifications.

If you can correct this flow it will be great.

Thank you.

you can see this by looking at contact header:

dump from physical interface to upstream
================
INVITE sip:1111 at 10.1.23.23;transport=UDP;user=phone SIP/2.0
Record-Route: <sip:10.56.42.23;r2=on;lr;ftag=34ff4c7e;did=0ce.621;nat=yes>
Record-Route: <sip:127.0.0.8;line=sr-BRwEk.dED.d0z.z0z.zvB.afyR8vygavebZAeL7LGVeJGVz2epcMQuTfzVGwD.1Szpc01rTfOuYL>
Via: SIP/2.0/UDP
10.56.42.23;branch=z9hG4bK4fed.265c2242365ddb0a53289d8a3eac05a7.0
Via: SIP/2.0/UDP
127.0.0.8;branch=z9hG4bKsr-s7wTDLa0zUfYZXl5zpl0zpl0z.lRD.zok.sEG.lvBJY.euwReuTfzpl0zpl0z.lRD.zokqZaxuZ9P.c3BJX01R5fO.wCZLZ3WSqMkhBqGgCceVT7G.G.epGwe.wAzh5jz37jDW7ceh52GpZKDpcSBVfSPh7qzh1E
Max-Forwards: 69
Contact: <sip:127.0.0.8;line=sr-BRwEk.z8zh1LGplEzhdRzsljzU8jzU8Szh10zLMKGplRzhc7BJX0B2n6BbTfYsZT>
To: <sip:1111 at 10.1.23.23;transport=UDP>
From: <sip:2222 at 10.1.23.23;transport=UDP>;tag=34ff4c7e
Call-ID: Y2EyYmU5NGZiNjYxMGY3MDc0M2ZhYTU1MmNkODFjOWQ.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS,
INFO, SUBSCRIBE
Content-Type: application/sdp
Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri
User-Agent: Z 3.3.25608 r25552
Allow-Events: presence, kpml
Content-Length: 382
P-Asserted-Identity: <sip:635000161 at SNSIP.LIFE.COM;user=phone>
Expires: 180

v=0
o=Z 0 0 IN IP4 10.56.42.23
s=Z
c=IN IP4 10.56.42.23
t=0 0
m=audio 18274 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=rtcp:18275
a=ice-ufrag:MyrLrVTV
a=ice-pwd:uoYbKhQTednj4xw3aF2R0ysK6R
a=candidate:1zTwRqKsCajOhkZK 1 UDP 2130706431 10.56.42.23 18274 typ host
a=candidate:1zTwRqKsCajOhkZK 2 UDP 2130706430 10.56.42.23 18275 typ host

================

dump from homer db

INVITE sip:1111 at 10.1.23.23;transport=UDP;user=phone SIP/2.0
Record-Route: <sip:10.56.42.23;r2=on;lr;ftag=34ff4c7e;did=0ce.621;nat=yes>
Record-Route: <sip:10.1.23.23;r2=on;lr;ftag=34ff4c7e;did=0ce.621;nat=yes>
Via: SIP/2.0/UDP
10.56.42.23;branch=z9hG4bK4fed.265c2242365ddb0a53289d8a3eac05a7.0
Via: SIP/2.0/UDP
10.10.206.39:5060;received=10.10.206.39;TH=div;branch=z9hG4bK-d8754z-dd463ce3ef9a0812-1---d8754z-;rport=5060
Max-Forwards: 69
Contact: <sip:2222 at 10.10.206.39:5060;transport=UDP>
To: <sip:1111 at 10.1.23.23;transport=UDP>
From: <sip:2222 at 10.1.23.23;transport=UDP>;tag=34ff4c7e
Call-ID: Y2EyYmU5NGZiNjYxMGY3MDc0M2ZhYTU1MmNkODFjOWQ.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS,
INFO, SUBSCRIBE
Content-Type: application/sdp
Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri
User-Agent: Z 3.3.25608 r25552
Allow-Events: presence, kpml
Content-Length: 382
TH: dih
P-Asserted-Identity: <sip:635000161 at SNSIP.LIFE.COM;user=phone>
Expires: 180

v=0
o=Z 0 0 IN IP4 10.56.42.23
s=Z
c=IN IP4 10.56.42.23
t=0 0
m=audio 18274 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=rtcp:18275
a=ice-ufrag:MyrLrVTV
a=ice-pwd:uoYbKhQTednj4xw3aF2R0ysK6R
a=candidate:1zTwRqKsCajOhkZK 1 UDP 2130706431 10.56.42.23 18274 typ host
a=candidate:1zTwRqKsCajOhkZK 2 UDP 2130706430 10.56.42.23 18275 typ host
--
Best regards,
Sergey Basov                     e-mail: sergey.v.basov at gmail.com

tel: (+38067) 403-62-54

2016-01-06 11:08 GMT+02:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>
>
> On 06/01/16 09:19, Sergey Basov wrote:
>> Sorry, not only ACK.
>> There is ACK, INVITE, ACK and BYE
>
> OK.
>
> I pushed two patches to master branch that should fix the issue with the
> error log messages. Can you test with master branch? If all goes fine,
> then I will consider backporting.
>
> For capturing the packets after topoh, more time is needed to analyze
> and implement if possible.
>
> Cheers,
> Daniel
>>
>> I am using kamailio as statefull proxy.
>>
>> So in case of normal callflow there is REGISTER and so on..
>>
>> And with sip_trace enabled in onsend_route errors in kamailio.log still persist.
>>
>> Jan  6 10:12:01 sip1 /usr/sbin/kamailio[30545]: INFO: <script>:
>> onsend_route entered !!!
>> Jan  6 10:12:01 sip1 /usr/sbin/kamailio[30545]: INFO: <core>
>> [parser/parse_fline.c:144]: parse_first_line():
>> ERROR:parse_first_line: method not followed by SP
>> Jan  6 10:12:01 sip1 /usr/sbin/kamailio[30545]: ERROR: <core>
>> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad
>> message (offset: 0)
>> Jan  6 10:12:01 sip1 /usr/sbin/kamailio[30545]: ERROR: <core>
>> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg:
>> message=<#002#020#002#021#023�#023�#0128*#027#0128*#024Q̌V��>
>>
>> Is there any possibility do sending message via siptrace module after
>> topoh module?
>>
>> WBR
>> --
>> Best regards,
>> Sergey Basov                     e-mail: sergey.v.basov at gmail.com
>>
>> tel: (+38067) 403-62-54
>>
>>
>> 2016-01-06 10:02 GMT+02:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>>> No other SIP requests? Only the ACK?
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 06/01/16 07:55, Sergey Basov wrote:
>>>> I just try it.
>>>> I got only last ACK when call was finished.
>>>>
>>>> I think than siptrace must catch and send duplicate message after topoh module.
>>>> Because  in other case we can see message as it is inside kamailio,
>>>> not message that will be send to upstream or client...
>>>>
>>>> WBR.
>>> --
>>> Daniel-Constantin Mierla
>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>> Book: SIP Routing With Kamailio - http://www.asipto.com
>>> http://miconda.eu
>>>
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Book: SIP Routing With Kamailio - http://www.asipto.com
> http://miconda.eu
>