inreq_allowed is missing from Wiki and if not allowed produced incorrect negative response about baresip HOT 10 CLOSED

#2953 Fixes the return code.

The wiki has been updated.

@juha-h We try to be very cooperative when proposing changes. Your mentioned issues were addressed in the PR, see this comment in particular. I stated:

Let me know if this is okay. If not, we will change the default to yes.

and got no response, but later a "looks okay to merge".

If the consensus is to allow incoming SIP MESSAGEs per default, then we will change the default and restore the old behavior.

@juha-h Please take into consideration the work we have done to improve BareSIP. We have contributed a lot and always take the community into account.

from baresip.

Maybe consider adding a warning if a message is rejected to avoid confusion when messages are not received. The rejection of messages is only visible when the sip trace is turned on.

from baresip.

the common policy during the years is to keep backwards compat when adding new features.
this is to keep the endusers happy.

from baresip.

The default value for this setting is not backwards compatible, that's why i think there should maybe be a warning or some other hint

from baresip.

I tried for vain to resist accepting the PR #2877 because it broke backwards compatibility. The PR also misses adding ;inreq_allowed to addr-params and into Wiki, and the negative response has wrong code. Further, the PR does not address security consideration in https://www.rfc-editor.org/rfc/rfc3428#section-11. In total, the PR should never have been accepted. My proposal is to revert it completely and pass the choice on what to do with incoming MESSAGE requests to the application.

from baresip.

We will update the wiki.

from baresip.

Updated: https://github.com/baresip/baresip/wiki/Accounts#inreq_allowed

Thanks for the hint!

from baresip.

Yes, you have contributed a lot, but that does not allow you to change our years long policy about backwards compatibility. In my comments about the PR I never gave up on that. On my second to last comment I wrote: This change is far too destructive, when the default is no.

from baresip.

Yes, you have contributed a lot, but that does not allow you to change our years long policy about backwards compatibility.

You are acting like we bypassed some policies. The PR went through a normal review process and your issues were specifically addressed. I literally asked

Let me know if this is okay. If not, we will change the default to yes.

and then got a "looks okay to merge".

In my comments about the PR I never gave up on that. On my second to last comment I wrote: This change is far too destructive, when the default is no.

Everyone can see that these comments were added after the PR had already been merged, we're not stupid.

#2961 Here's the PR that restores the old behavior, simply because I don't want to deal with this anymore.

from baresip.

from baresip.