[prev in list] [next in list] [prev in thread] [next in thread] 

List:       asterisk-dev
Subject:    Re: [asterisk-dev] [Code Review] SIP: session timer behavior in
From:       CDR <venefax () gmail ! com>
Date:       2010-08-29 18:44:54
Message-ID: AANLkTim7CLDq4zmtr_f3cpfteJi48TVDTYSWPx+sPj2r () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


I support these changes. In fact, just had a big issue with a major carrier
because of the "require Timer" feature. Please remove it from the INVITE
when the timer fires.
F.Alves

On Thu, Aug 26, 2010 at 3:06 PM, David Vossel <dvossel@digium.com> wrote:

>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/879/
> -----------------------------------------------------------
>
> Review request for Asterisk Developers.
>
>
> Summary
> -------
>
> This is a simple patch.  This review is more to verify my expectations of
> how Session Timers are supposed to work are sane.
>
> CHANGES:
> 1. Never put "timer" in "Require" header.  This is not to our benefit and
> RFC 4028 section 7.1 even warns against it.  It is possible for one endpoint
> to perform session-timer refreshes while the other endpoint does not support
> them.  If in this case the end point performing the refreshing puts "timer"
> in the Require field during a refresh, the dialog will likely get terminated
> by the other end.
>
> 2. Change the behavior of 'session-timer=accept' in sip.conf (which is the
> default behavior of Asterisk with no session timer configuration specified)
> to only run session-timers as result of an incoming INVITE request if the
> INVITE contains an "Session-Expires" header... Asterisk is currently
> treating having the "timer" option in the "Supported" header as a request
> for session timers by the UAC.  I do not agree with this.  Session timers
> should only be negotiated in "accept" mode when the incoming INVITE supplies
> a "Session-Expires" header, otherwise RFC 4028 says we should treat a
> request containing no "Session-Expires" header as a session with no
> expiration.
>
> Below I have outlined some situations and what I would Asterisk's behavior
> to be.  The table reflects the behavior changes implemented by this patch.
>
> SITUATIONS:
> -Asterisk as UAS
> 1. Incoming INVITE: NO  "Session-Expires"
> 2. Incoming INVITE: HAS "Session-Expires"
>
> -Asterisk as UAC
> 3. Outgoing INVITE: NO  "Session-Expires". 200 Ok Response HAS
> "Session-Expires" header
> 4. Outgoing INVITE: NO  "Session-Expires". 200 Ok Response NO
>  "Session-Expires" header
> 5. Outgoing INVITE: HAS "Session-Expires".
>
> Active   - Asterisk will have an active refresh timer regardless if the
> other endpoint does.
> Inactive - Asterisk does not have an active refresh timer regardless if the
> other endpoint does.
> XXXXXXX  - Not possible for mode.
> ______________________________________
> |SITUATIONS | 'session-timer' MODES  |
> |___________|________________________|
> |           | originate  |  accept   |
> |-----------|------------|-----------|
> |1.         |   Active   | Inactive  |
> |2.         |   Active   |  Active   |
> |3.         | XXXXXXXX   | Active    |
> |4.         | XXXXXXXX   | Inactive  |
> |5.         |   Active   | XXXXXXXX  |
> --------------------------------------
>
>
> This addresses bug 17005.
>    https://issues.asterisk.org/view.php?id=17005
>
>
> Diffs
> -----
>
>  /branches/1.8/channels/chan_sip.c 283768
>
> Diff: https://reviewboard.asterisk.org/r/879/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> David
>
>
> --
> _____________________________________________________________________
> -- 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
>

[Attachment #5 (text/html)]

I support these changes. In fact, just had a big issue with a major carrier because \
of the &quot;require Timer&quot; feature. Please remove it from the INVITE when the \
timer fires.<div>F.Alves<br><br><div class="gmail_quote"> On Thu, Aug 26, 2010 at \
3:06 PM, David Vossel <span dir="ltr">&lt;<a \
href="mailto:dvossel@digium.com">dvossel@digium.com</a>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <div class="im"><br>
-----------------------------------------------------------<br>
This is an automatically generated e-mail. To reply, visit:<br>
</div><a href="https://reviewboard.asterisk.org/r/879/" \
                target="_blank">https://reviewboard.asterisk.org/r/879/</a><br>
-----------------------------------------------------------<br>
<div class="im"><br>
Review request for Asterisk Developers.<br>
<br>
<br>
</div>Summary<br>
-------<br>
<br>
This is a simple patch.  This review is more to verify my expectations of how Session \
Timers are supposed to work are sane.<br> <br>
CHANGES:<br>
1. Never put &quot;timer&quot; in &quot;Require&quot; header.  This is not to our \
benefit and RFC 4028 section 7.1 even warns against it.  It is possible for one \
endpoint to perform session-timer refreshes while the other endpoint does not support \
them.  If in this case the end point performing the refreshing puts &quot;timer&quot; \
in the Require field during a refresh, the dialog will likely get terminated by the \
other end.<br>

<br>
2. Change the behavior of &#39;session-timer=accept&#39; in sip.conf (which is the \
default behavior of Asterisk with no session timer configuration specified) to only \
run session-timers as result of an incoming INVITE request if the INVITE contains an \
&quot;Session-Expires&quot; header... Asterisk is currently treating having the \
&quot;timer&quot; option in the &quot;Supported&quot; header as a request for session \
timers by the UAC.  I do not agree with this.  Session timers should only be \
negotiated in &quot;accept&quot; mode when the incoming INVITE supplies a \
&quot;Session-Expires&quot; header, otherwise RFC 4028 says we should treat a request \
containing no &quot;Session-Expires&quot; header as a session with no expiration.<br>

<br>
Below I have outlined some situations and what I would Asterisk&#39;s behavior to be. \
The table reflects the behavior changes implemented by this patch.<br> <br>
SITUATIONS:<br>
-Asterisk as UAS<br>
1. Incoming INVITE: NO  &quot;Session-Expires&quot;<br>
2. Incoming INVITE: HAS &quot;Session-Expires&quot;<br>
<br>
-Asterisk as UAC<br>
3. Outgoing INVITE: NO  &quot;Session-Expires&quot;. 200 Ok Response HAS \
&quot;Session-Expires&quot; header<br> 4. Outgoing INVITE: NO  \
&quot;Session-Expires&quot;. 200 Ok Response NO  &quot;Session-Expires&quot; \
header<br> 5. Outgoing INVITE: HAS &quot;Session-Expires&quot;.<br>
<br>
Active   - Asterisk will have an active refresh timer regardless if the other \
endpoint does.<br> Inactive - Asterisk does not have an active refresh timer \
regardless if the other endpoint does.<br> XXXXXXX  - Not possible for mode.<br>
______________________________________<br>
> SITUATIONS | &#39;session-timer&#39; MODES  |<br>
> ___________|________________________|<br>
> > originate  |  accept   |<br>
> -----------|------------|-----------|<br>
> 1.         |   Active   | Inactive  |<br>
> 2.         |   Active   |  Active   |<br>
> 3.         | XXXXXXXX   | Active    |<br>
> 4.         | XXXXXXXX   | Inactive  |<br>
> 5.         |   Active   | XXXXXXXX  |<br>
--------------------------------------<br>
<br>
<br>
This addresses bug 17005.<br>
    <a href="https://issues.asterisk.org/view.php?id=17005" \
target="_blank">https://issues.asterisk.org/view.php?id=17005</a><br> <br>
<br>
Diffs<br>
-----<br>
<br>
  /branches/1.8/channels/chan_sip.c 283768<br>
<br>
Diff: <a href="https://reviewboard.asterisk.org/r/879/diff" \
target="_blank">https://reviewboard.asterisk.org/r/879/diff</a><br> <br>
<br>
Testing<br>
-------<br>
<br>
<br>
Thanks,<br>
<br>
David<br>
<br>
<br>
--<br>
<div class="im">_____________________________________________________________________<br>
                
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" \
target="_blank">http://www.api-digital.com</a> --<br> <br>
</div>asterisk-dev mailing list<br>
<div class="im">To UNSUBSCRIBE or update options visit:<br>
</div>   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" \
target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br> \
</blockquote></div><br></div>



-- 
_____________________________________________________________________
-- 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

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic