[asterisk-dev] [Code Review] chan_sip: Make the session-timers 'require: timer' header an option

[Darren Sessions]

Bit fuzzy on the proposed new "accept" mode.

So if an outgoing call is placed, and a '420 Bad extension' is
received, are we saying a new invite gets sent out immediately with
the supported-header? Seems a bit redundant to retry the outbound call
if the mode is accept and the new originate mode does the outbound
calls with the supported header.

Would seem to make more sense, at least to me, in that scenario if I
was making outbound calls to whomever that was requiring at least a
minimum of the supported-header to just use the originate mode instead
making the accept mode retry the call. Am I missing something?

Just a thought . .


On Thu, Jun 10, 2010 at 5:59 AM, Kevin P. Fleming <kpfleming at digium.com> wrote:
> On 06/10/2010 03:38 AM, Nick Lewis wrote:
>
>> I think the modes and behaviour could be as follows:
>> refuse: for outgoing calls do not add to supported-header;
>>         for incoming calls do not add to supported-header even if received with required-header
>
> This one is a violation of the SIP RFCs, please do not implement it. If
> an incoming Require header includes 'timer', and the UA does not wish to
> support Session-Timer, the *only* recourse it has is to reply with a
> '420 Bad Extension'.
>
>> accept: for outgoing calls do not add to supported-header but retry with it added to supported-header if a required-header rejection is received;
>>         for incoming calls add to supported-header if received with supported-header
>> (new)originate: for outgoing calls add to supported-header but not required-header;
>>                 for incoming calls add to supported-header if received with supported-header
>> require(oldorig): for outgoing calls add to supported-header and required-header;
>>                    for incoming calls add to supported-header and required-header even if not received with supported-header
>>
>> If originate cannot be renamed for backward compatibility then the last two could be negotiate and originate
>
> Otherwise this seems like a reasonable approach.
>
> --
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> skype: kpfleming | jabber: kfleming at digium.com
> Check us out at www.digium.com & www.asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>