Didn't #2769 fix it?

Can you describe what it fixes now, after #2769 was merged? Eventually provide the logs with debug=3 when facing the issue that this PR is supposed to fix.

It's work badly for 'o=' and 'c=', doesn't return an error on incorrect lines.

Thanks for the pull request. I do not think that "dirty" is a good way to describe another pull request from a contributor. The regression was probably not anticipated, everybody makes mistakes sometimes.

@linuxmaniac can you maybe also do a quick review on the refactoring done in this request?

@miconda I do not understand the reasons for this bulling. I'm not trying to offend anyone. If you are ready to continue, I am ready to explain in more detail what problems I have found and fixed.

@dwagin - what do you try to do now?!? Accuse me because I asked details about if this PR makes sense anymore and if yes, explain what it does and what it fixes and you just reply:

``` The main reason of my changes: #2769 is buggy and dirty. ```

Which is simply insulting the people involved in that PR. Later you followed up with `violates`, not a word that is appropriate in constructive discussions. You didn't provide anything technical.

I wanted to make sure that you understand this project is not where people insult each other, either you can collaborate with a decent vocabulary or go away. It is not bullying at all, it is common sense. In turn, you come back and accuse of bullying because I said your comments are clearly inappropriate and offend, instead of continuing with a technical discussion as I mention in my previous comment it is the way to go.

There is requirement for a specific programming design principle to contribute to the project. There are so many such principles, many contradicting themselves. That's more like a bikeshedding discussion. The code must be easy to understand and more important, supported by a trusted developer.

It is somehow contradicting that you feel there is no review process in this project, when this actually happens now and happened to your first PR on this matter. I do not use that function and had no time to setup a testbed, I asked to see if anyone else can help (e.g., pinging `oej`). Soon after yours, Victor proposed a PR that touched the same code and had somehow the same description (you see, I looked at the patches and understood what they touch), we tried to get everyone involved in the two PRs to discuss and conclude what is the better way to go forward.

With lack of your reaction, I decided to merge the one from Victor in preparation to v5.5.1, because it was simple, not intrusive, but more important Victor has quite some reputation in the project, with over 850 commits since 2012, thus I know that he can react if he needs to fix eventual regressions, not to count that he works on one of the most deployed VoIP systems built with Kamailio (i.e., `sip:provider ce`), so there is enough trust and expertise in that team they do not just submit patches for the sake of doing it. Even more proving that reviews are done in this project, it was my follow up commit to check on the length, as I noticed the potential problems there -- however, I decided to do it myself after merging PR for time reasons.

Regarding the list of banned words, it is actually not only about the individual words, but also the context. If you want to keep it decent, just stick to pure technical discussions and technical details. There is no value in only aesthetic remarks, like "ugly and buggy" or "looks like duct tape". Instead, you can just say: with PR #abcd merged, now I get the following errors, next are the syslog message:

``` ... ```

Here is the INVITE that causes these logs to be printed:

``` ... ```

I propose this new commit, which also follows a commonly accepted programming design principle named NM (link here).

To end the topic on words, one can also use "good" words to insult others in specific contexts, like "yeah, yeah, that's so smart, aiming for Nobel prize next year?!?". Hope you understand now the scope and that a list of banned words won't solve it, human communications and relations is not mathematics.

I haven't seen the criticism to me, only flipping the coin to shortly blame of bullying. But tastes and feelings are personal, so I can go over, during the past 20 years involved in Kamailio development I have seen worse accusations targeting me.

Rather lengthly post so far, but I wanted to make some points clear. We do welcome contributions and contributors when they are respectful:

* https://github.com/kamailio/kamailio/blob/master/CODE_OF_CONDUCT.md

And that's it from my side on non-technical aspects -- from now on, let's try to simply discuss on technical details.

So ... unfortunately, it is sill not clear for me if the code right now in master branch has issues (prints error logs messages or does not work properly) or you don't like the previous fix and want to improve it (which is fine, enhancements are welcome as well, just that we have to know from what perspective to look at it). If any other Kamailio developer understood, I am fine if someone else wants to take over.

Otherwise, if it is still the case of issues, attach the logs printed by kamailio with `debug=3` in kamailio.cfg and provide also the SIP INVITE that triggers them, so we can analyze and test the commit of this PR.

So as the original reporter do not seems to want to follow up further, maybe @linuxmaniac can have a quick look on the described issue if its valid: "If SDP didn't have an "a=rtcp" header (RFC1889 behavior), Kamailio had thrown an Error can't extract 'a=rtcp' IP from the SDP on every INVITE. After the PR Kamailio does not flood into log.".