[asterisk-dev] [asterisk-commits] oej: branch oej/darjeeling-prack-1.8 r369555 - /team/oej/darjeeling-prack-1.8/

[Tilghman Lesher]

On Thu, Jul 5, 2012 at 2:43 PM, Kevin P. Fleming <kpfleming at digium.com> wrote:
> On 07/05/2012 02:29 PM, Olle E. Johansson wrote:
>> 5 jul 2012 kl. 20:42 skrev Kevin P. Fleming:
>>>
>>> If a new RFC appears that obsoletes RFC3262, it will likely also change
>>> the mechanism, and in that case, the Asterisk code would need to be changed
>>> to become compliant with the new RFC, and users would need to be given
>>> configuration option(s) to control the new and old behaviors. I don't find
>>> this 'stupid' at all, but I'm certainly open to other suggestions if anyone
>>> has any.
>>>
>> The unique thing with RFC3292 is the PRACK method. That's why I named the
>> option PRACK.
>>
>> Easier to explain, teach and remember.
>
> The '100rel' option tag is also unique, and in my opinion is more relevant,
> because that's what appears in the Supported and Require headers (not
> PRACK), so that's really the 'feature' being added here. I didn't suggest
> that the config option be named '100rel', though because it's too arcane and
> is not at all descriptive.

The potential for fat-fingering, as has been made clear by the above
exchange, without easily catching it, makes any numbers in an option
name perilous.  Even our use of 'rfc2833' in Asterisk is as an option
value, not an option name.  I would additionally point out that we're
talking about chan_sip, not chan_rfc3261. :-)  Given that 'prack'
appears in the Abstract for the RFC, it's a good, logical choice.
Another good choice might be to use the RFC title,
provisionalresponses=supported|required|no.

-Tilghman