With the config that we use for Kamailio, when we enable the track_cseq_updates option on the dialog module (for use with uac_auth()) it causes Kamailio to start failing on parse_first_line() with the following error:
2(6160) INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP 2(6160) ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) 2(6160) ERROR: <core> [parser/msg_parser.c:690]: parse_msg(): ERROR: parse_msg: message=<ÄÜ s2¬>
If you look at the 3rd line of the error it looks like the pointer to the message or the message itself somehow gets corrupted. If I simply switch off the track_cseq_updates option it starts to function normally again.
I'm sorry I don't have a config file I can give as an example because the minimalist config I tried creating with that option on worked fine, so there must be something in our config that's leading to this issue but I'm unable to include our config. =/
I'm working on tracking down the issue myself but I wanted to create this issue in case anyone has run into this before or has any pointers on where I should look to reduce the amount of code I need to look through.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/526
I've tracked this issue down to a combination of using HEP mode siptrace and turning on the track_cseq_updates at the same time. It looks like when HEP mode is turned on it adds the HEP header in front of the message it's duplicating, then uses msg_send() to send it. When this happens the callback for SREV_NET_DATA_OUT triggers dlg_cseq_msg_sent() in the dialog module which runs a parse_msg() on the buffer sent in. Since the buffer has the HEP data in the front when it tries to parse the message it leads to a parse error.
I'm not sure how to fix this, though, since there's really only this special case where msg_send() has some additional metadata at the beginning of the data.
This is a minimal config that reproduces the issue: [kam-cseq-parse-error.txt](https://github.com/kamailio/kamailio/files/155253/kam-cseq-parse-error.txt)
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/526#issuecomment-191327909
I was going to work on a fix for this in master today but it appears it was already fixed by 284c11ed16bdc5afcc9abf49c9f5c1749ce831e0 though. I do have a concern about the fix, though. The fix was to just not issue the callback when sending a siptrace duplicate. Would this then mean that in the case of the track_cseq_updates that the cseq in HEP siptrace messages would be inconsistent with what's actually being sent?
I was thinking of doing something like msg_send_metadata() that would take a header and footer size and then only pass the message part to the event callback. In that case the message would still be updated by any callbacks but not cause errors on any parse_msg calls within the callback.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/526#issuecomment-193392646
Closed #526.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/526#event-580702855
Have checked to see how is the cseq sent to homer? Is the one sent out on sip channel?
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/526#issuecomment-193432708
I haven't had a chance to check yet. I just cherry-picked the fixes into our stable branch and I'm going to be testing it shortly.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/526#issuecomment-193433125
I just ran some tests and it does look like the CSeq is being sent with a different value between the two. I see `CSeq: 2 INVITE` going to homer and `CSeq: 4 INVITE` going to FreeSwitch for the same message.
If you like the solution I proposed above (the msg_send_metadata() one) and can't think of any issues it would cause I can get that implemented with a PR.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/526#issuecomment-193465136
Reopened #526.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/526#event-580815299
Have you tried with trace mode 1?
* http://www.kamailio.org/docs/modules/stable/modules/siptrace.html#siptrace.p...
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/526#issuecomment-204310048
Closed #526.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/526#event-639505607
If trace_mode doesn't solve, then making a PR with metadata could be an approach. Closing this one here.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/526#issuecomment-214175410
-
Daniel-Constantin Mierla -
Erik Davidson