[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [asterisk-dev] [Code Review]: SIP session timers: Add Require: timer to appropriate responses
From: "Mark Michelson" <reviewboard () asterisk ! org>
Date: 2012-10-31 20:23:43
Message-ID: 20121031202343.1834.12839 () hotblack ! digium ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Oct. 31, 2012, 11:58 a.m., Olle E Johansson wrote:
> > @matt: I did not require anything or refer to any policy. Please calm down.
> >
> > Now, do we parse incoming Require: headers to our INVITE? That part is also in my \
> > code. If the other side does NOT add a Require header we're running stand-alone \
> > mode, but can still activate session timers. If the other side adds a Require \
> > header, we're in the play.
I just want to make sure I understand this comment before I add a new revision:
"do we parse incoming Require: headers to our INVITE?"
Are you asking if we parse Require headers in responses to our INVITE? If that's the \
question, then no we do not in current 1.8. Based on my reading of RFC 4028, I don't \
think it's really necessary for us to read a Require header in a response. Let's go \
over the various scenarios where Asterisk is the one placing the original INVITE:
* session-timers=originate
* session-refresher=uac
When Asterisk sends an INVITE out, it includes a Supported: timer header and a \
Session-Expires header. In this situation, the far end MUST send Require: timer in \
the 200 OK. We don't look for this header, but we do look for a Session-Expires \
header to determine the refresh interval. If the far end overrides our refresher \
preference, then we'll honor their preference.
* session-refresher=uas
When Asterisk sends an INVITE out, it includes a Supported: timer header and a \
Session-Expires header. In this situation, the far end SHOULD send Require: timer in \
the 200 OK. We don't look for this header, but we do look for a Session-Expires \
header to determine the refresh interval. If the far end overrides our refresher \
preference, then we'll honor their preference.
* session-timers=accept
In this mode, Asterisk's behavior is the same no matter what session-refresher is \
set to. When Asterisk sends an INVITE out, it includes a Supported: timer header and \
a Session-Expires header. In this situation, the far end SHOULD send Require: timer \
in the 200 OK. We don't look for this header, but we do look for a Session-Expires \
header to determine the refresh interval. We will let the far end decide who the \
refresher is.
* session-timers=refuse
In this mode, Asterisk's behavior is the same no matter what session-refresher is \
set to. When Asterisk sends an INVITE out, it does not include a Supported: timer \
header, nor does it include a Session-Expires header. In this situation, RFC 4028 \
does not explicitly say whether the UAS should or should not include a Require: timer \
header in the 200 OK. In this situation, Asterisk does not inspect the Require header \
and it will also ignore the Session-Expires header in the 200 OK response. In theory, \
this is because Asterisk is refusing to use session timers. In such a case, the UAS \
would be responsible for all refreshes, and Asterisk simply does not care about \
session expiry. Whether this is actually compliant, I'm not sure, since it appears \
that the UAS is the entity that gets to decide in the end whether there is a session \
timer in use or not.
So let's sum up. In every case where there might be a Require: timer, there will also \
be a Session-Expires header. If we're looking at the Session-Expires header, then is \
it really necessary for us to also inspect the Require header? Does the presence of a \
Require header in addition to a Session-Expires header change how we should behave? I \
don't think it does, actually. Looking at your branch, you get the Require header \
value but all you do is print a debug message if it was set to "timer". There's no \
additional processing done.
- Mark
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2172/#review7345
-----------------------------------------------------------
On Oct. 31, 2012, 11:05 a.m., Mark Michelson wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2172/
> -----------------------------------------------------------
>
> (Updated Oct. 31, 2012, 11:05 a.m.)
>
>
> Review request for Asterisk Developers.
>
>
> Summary
> -------
>
> This patch makes it so Asterisk adds Require: timer when appropriate when sending \
> INVITE responses.
> If session timers are in use, then there are two situations under which we'll add \
> the header:
> 1) We are sending a 200 OK with a Session-Expires header that has a refresher \
> parameter of "uac" 2) We are sending a 200 OK with a Session-Expires header that \
> has a refresher parameter of "uas" and the INVITE to which we are responding had a \
> Supported: timer header in it.
> This patch also introduces another change. Prior to this change, the only way we \
> would add a Session-Expires header in an INVITE response was if the inbound INVITE \
> had a Supported: timer header in it. Now we always add this header if Asterisk \
> using session-timers=originate. This is based on a table in section 9 of RFC 4028. \
> It indicates that if the UAC does not support Session-Timers but the UAS does, then \
> the UAS should send a Session-Expires header with a refresher parameter of "uas".
>
> This addresses bug ASTERISK-20570.
> https://issues.asterisk.org/jira/browse/ASTERISK-20570
>
>
> Diffs
> -----
>
> /branches/1.8/channels/chan_sip.c 375481
> /branches/1.8/channels/sip/include/sip.h 375481
>
> Diff: https://reviewboard.asterisk.org/r/2172/diff
>
>
> Testing
> -------
>
> Tried the following three scenarios that should have resulted in Asterisk sending a \
> 200 OK with a Require: timer:
> 1. INVITE with refresher=uac
> 2. INVITE with refresher=uas
> 3. INVITE with no Session-Expires but with Supported: timer
>
> I also tried the following scenario that should result in a 200 OK with a \
> Session-Expires (refresher=uas) but no Require: timer header:
> INVITE with no Supported: timer header present.
>
> I plan on turning this into a testsuite test as well.
>
>
> Thanks,
>
> Mark
>
>
[Attachment #5 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/2172/">https://reviewboard.asterisk.org/r/2172/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On October 31st, 2012, 11:58 a.m., <b>Olle E \
Johansson</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">@matt: I did not require anything or refer to any policy. Please calm \
down.
Now, do we parse incoming Require: headers to our INVITE? That part is also in my \
code. If the other side does NOT add a Require header we're running stand-alone \
mode, but can still activate session timers. If the other side adds a Require header, \
we're in the play.</pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I just want to make sure \
I understand this comment before I add a new revision:
"do we parse incoming Require: headers to our INVITE?"
Are you asking if we parse Require headers in responses to our INVITE? If that's \
the question, then no we do not in current 1.8. Based on my reading of RFC 4028, I \
don't think it's really necessary for us to read a Require header in a \
response. Let's go over the various scenarios where Asterisk is the one placing \
the original INVITE:
* session-timers=originate
* session-refresher=uac
When Asterisk sends an INVITE out, it includes a Supported: timer header and a \
Session-Expires header. In this situation, the far end MUST send Require: timer in \
the 200 OK. We don't look for this header, but we do look for a Session-Expires \
header to determine the refresh interval. If the far end overrides our refresher \
preference, then we'll honor their preference.
* session-refresher=uas
When Asterisk sends an INVITE out, it includes a Supported: timer header and a \
Session-Expires header. In this situation, the far end SHOULD send Require: timer in \
the 200 OK. We don't look for this header, but we do look for a Session-Expires \
header to determine the refresh interval. If the far end overrides our refresher \
preference, then we'll honor their preference.
* session-timers=accept
In this mode, Asterisk's behavior is the same no matter what session-refresher \
is set to. When Asterisk sends an INVITE out, it includes a Supported: timer header \
and a Session-Expires header. In this situation, the far end SHOULD send Require: \
timer in the 200 OK. We don't look for this header, but we do look for a \
Session-Expires header to determine the refresh interval. We will let the far end \
decide who the refresher is.
* session-timers=refuse
In this mode, Asterisk's behavior is the same no matter what session-refresher \
is set to. When Asterisk sends an INVITE out, it does not include a Supported: timer \
header, nor does it include a Session-Expires header. In this situation, RFC 4028 \
does not explicitly say whether the UAS should or should not include a Require: timer \
header in the 200 OK. In this situation, Asterisk does not inspect the Require header \
and it will also ignore the Session-Expires header in the 200 OK response. In theory, \
this is because Asterisk is refusing to use session timers. In such a case, the UAS \
would be responsible for all refreshes, and Asterisk simply does not care about \
session expiry. Whether this is actually compliant, I'm not sure, since it \
appears that the UAS is the entity that gets to decide in the end whether there is a \
session timer in use or not.
So let's sum up. In every case where there might be a Require: timer, there will \
also be a Session-Expires header. If we're looking at the Session-Expires header, \
then is it really necessary for us to also inspect the Require header? Does the \
presence of a Require header in addition to a Session-Expires header change how we \
should behave? I don't think it does, actually. Looking at your branch, you get \
the Require header value but all you do is print a debug message if it was set to \
"timer". There's no additional processing done.</pre> <br />
<p>- Mark</p>
<br />
<p>On October 31st, 2012, 11:05 a.m., Mark Michelson wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By Mark Michelson.</div>
<p style="color: grey;"><i>Updated Oct. 31, 2012, 11:05 a.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">This patch makes it so Asterisk adds Require: timer when appropriate \
when sending INVITE responses.
If session timers are in use, then there are two situations under which we'll add \
the header:
1) We are sending a 200 OK with a Session-Expires header that has a refresher \
parameter of "uac" 2) We are sending a 200 OK with a Session-Expires header \
that has a refresher parameter of "uas" and the INVITE to which we are \
responding had a Supported: timer header in it.
This patch also introduces another change. Prior to this change, the only way we \
would add a Session-Expires header in an INVITE response was if the inbound INVITE \
had a Supported: timer header in it. Now we always add this header if Asterisk using \
session-timers=originate. This is based on a table in section 9 of RFC 4028. It \
indicates that if the UAC does not support Session-Timers but the UAS does, then the \
UAS should send a Session-Expires header with a refresher parameter of \
"uas".</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Tried the following three scenarios that should have resulted in \
Asterisk sending a 200 OK with a Require: timer:
1. INVITE with refresher=uac
2. INVITE with refresher=uas
3. INVITE with no Session-Expires but with Supported: timer
I also tried the following scenario that should result in a 200 OK with a \
Session-Expires (refresher=uas) but no Require: timer header:
INVITE with no Supported: timer header present.
I plan on turning this into a testsuite test as well.</pre>
</td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/ASTERISK-20570">ASTERISK-20570</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/branches/1.8/channels/chan_sip.c <span style="color: grey">(375481)</span></li>
<li>/branches/1.8/channels/sip/include/sip.h <span style="color: \
grey">(375481)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/2172/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
--
_____________________________________________________________________
-- 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