This feature was rejected by FESCo, due to the fact that user documentation is lacking, and many FESCo members were unsure of what this actually did. If FESCo members are confused about what this does, there's no hope that the average user will know.

Please resubmit this feature with better user-facing documentation

Please note that most of us appeared to like the feature in principle (at least judging from as far as we understood it), so it has a high chance of being accepted once properly documented.

Replying to [comment:2 kkofler]:

Please note that most of us appeared to like the feature in principle (at least judging from as far as we understood it), so it has a high chance of being accepted once properly documented.

This was my first effort at doing a feature spec, so I was unsure what even needed to be done. I choose to do it now, and schedule it for F13, largely because I thought there might be some help needed in understanding how to define it correctly and that there would be good lead time for doing that if I added it now and got feedback early.

What is the process to resubmit the feature??

Essentially, expand/rewrite sections 1.1, 1.4, 1.5, so that FESCo and users can understand how this benefits them. From the reading FESCo had, it wasn't quite clear what benefits this gave the user, how it interacts with SIP clients, asterisk, etc.

Then, mark the feature again for the wrangler to review, who will send it to FESCo again.

I have re-drafted the feature to, I hope, better communicate what it actually does :). If you have a chance to give it a quick look to see if it at least is more clear before I add it back to the que, I would be happy to hear what you think.

Replying to [comment:3 dyfet]:

Replying to [comment:2 kkofler]:

Please note that most of us appeared to like the feature in principle (at least judging from as far as we understood it), so it has a high chance of being accepted once properly documented.

Reopening based on feature resubmission

This feature was approved for F13