Subject: [Sip] Possible problem (?) regarding SUBSCRIBE

From: "Nicholas Mattiello" <[email-masked]>
Date: Wed, 5 Sep 2007 16:19:12 -0400

Hello,

Let me begin by saying I am relatively new to SIP.  I graduated 2 years ago
and since worked for a VoIP provider.  I am not a SIP expert, but I came
across some funky behavior and decided I should look into it.  I apologize
in advance if this has been addressed or if its not a problem.

I am currently working on presence event stuff for the SIP client I am
working on.  I recently noticed my Linux machine, which houses a proxy, was
constantly writing/reading from the hard drive at short regular intervals.
I did an ethereal trace and my client was sending SUBSCRIBEs at an ungodly
rate, causing the proxy to constantly write new subscription information to
the database.  I also noticed that my initial Expires header value was
different from the SUBSCRIBEs being sent (it defaults to 180, but the
Expires value i was seeing was now at 10).   I then noticed that the new
Expires value matched that of an expires parameter within the
Subscription-State header of a NOTIFY.

After looking into it, this is desired behavior according to RFC3265.  It
says:

If the value of the "Subscription-State" header is "active" or
"pending", the notifier SHOULD also include in the "Subscription-
State" header an "expires" parameter which indicates the time
remaining on the subscription.
...
If the "Subscription-State" header value is "active", it means that
the subscription has been accepted and (in general) has been
authorized.  If the header also contains an "expires" parameter, the
subscriber SHOULD take it as the authoritative subscription duration
and adjust accordingly.

So if there is 5 seconds left on a subscription, and a client receives a
NOTIFY, the client changes the Expires of any subsequent SUBSCRIBEs for that
event to 5 seconds, and requires a refresh at less than 5 second intervals.
The longer the client runs, the smaller this value will become.

This sounds like a problem to me, as a compliant client can start to flood a
compliant proxy.  Again I apologize if this has already been taken care of,
or if I am just reading this wrong, but the behavior within my compliant
proxy/compliant SIP API backs it up.

Thanks for your time.
-Nick
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Vikram Chhibber" <[email-masked]>
Date: Thu, 6 Sep 2007 14:22:34 +0530

To teach your client a lesson, you need to configure your notifier
application to reject SUBSCRIBE if expires is lower that its
configured acceptable value. You need to investigate on how to
configure this in your notifier.

3.1.6.1. Initial SUBSCRIBE Transaction Processing
   The notifier MAY also check that the duration in the "Expires" header
   is not too small.  If and only if the expiration interval is greater
   than zero AND smaller than one hour AND less than a notifier-
   configured minimum, the notifier MAY return a "423 Interval too
   small" error which contains a "Min-Expires" header field.  The "Min-
   Expires" header field is described in SIP [1].

Hope this will help you.
Also, use [email-masked] for questions on current sip

~Vikram
On 9/6/07, Nicholas Mattiello <[email-masked]> wrote:
> Sip mailing list
> https://www1.ietf.org/mailman/listinfo/sip

---

From: "Michael Procter" <[email-masked]>
Date: Thu, 6 Sep 2007 02:51:36 -0700

Hi Nicholas,

[RFC3265 extracts]

> So if there is 5 seconds left on a subscription, and a client receives 
> a NOTIFY, the client changes the Expires of any subsequent SUBSCRIBEs 
> for that event to 5 seconds, and requires a refresh at less than 5
> second intervals.  The longer the client runs, the smaller this value
> will become. 

I think you have misunderstood RFC3265 in this matter.  If the client receives a NOTIFY with "Expires: 5", it should infer that the current subscription will expire in 5 seconds.  If it wishes to extend the subscription, it will need to send a reSUBSCRIBE.  It does not need to resubscribe with an expiry of 5 seconds!  Instead, it may choose a different one (whatever worked the first time would be a good choice).

So, a typical flow could look something like this:

SUBSCRIBE (Expires:180) --->    # Initial subscribe requesting 180 secs
<--- 200
<--- NOTIFY (Expires: 180)	  # Note need to resubscribe in 180 secs
200 --->

(time passes (137 secs), something happens)
<--- NOTIFY (Expires: 43)	  # Note need to resubscribe in 43 secs
200 --->

(another 23 seconds pass, client decides to extend subscription, as only
20 seconds remain)
SUBSCRIBE (Expires: 180) --->
<--- 200
<--- NOTIFY (Expires: 180)	  # Subscription extended for 3 mins
200 --->

I hope this clarifies things,

Michael

---

From: "Nicholas Mattiello" <[email-masked]>
Date: Thu, 6 Sep 2007 10:46:56 -0400

The use of INFO part.  Hey, I'm not totally Henry - I do see a place for
communications service providers and I recognize the importance of
interworking with the PSTN for the next 15 years.

SIP-T is not a session initiation protocol.  It is a set of conventions
for TUNNELING proprietary signaling events over SIP.  Key word there is
TUNNELING.  That is the clue that section 3.3 applies.

On 9/5/07 6:46 AM, "Bram Verburg" <[email-masked]> wrote:

> OK, SIP-T is not going away, but I'm still not sure whether you are=20
> trying to say that all of SIP-T is bad, or only its use of INFO? If
all
> of SIP-T is bad, then let's not fix it and wait till it does go away=20
> eventually. If the problem is specifically with INFO, then let's
define
> an event package that allows endpoints to request mid-call
'proprietary'
> signaling events, and then we can deprecate INFO altogether.
>=20
> My point was that SIP-T is not simply a tunnel that could be replaced
by
> any other transport layer, which is what section 3.3 seems to
describe.
> It is a 'session initiation protocol' that does exactly what SIP is=20
> designed to do: initiate sessions. The fact that the INFO method has a

> problem doesn't mean that SIP-T is an inappropriate use of SIP.
>=20
> Bram
>=20
>=20
>> -----Original Message-----
>> From: Eric Burger [mailto:[email-masked]]
>> Sent: 05 September 2007 16:09
>> To: Bram Verburg
>> Cc: sip
>> Subject: Re: [Sip] INFO
>>=20
>> SIP-T suffers *all* of the issues with INFO.
>>=20
>> Read section 3.3 for the 'right' way of doing SIP-T.
>>=20
>> That said, let's be real: I don't think anyone will abandon SIP-T at=20
>> this late date.  Although this really is a counter example, I would=20
>> liken this to the story in:
>> http://www.snopes.com/history/american/gauge.htm
>>=20
>>=20
>>=20
>>=20
>> On 9/5/07 4:56 AM, "Bram Verburg" <[email-masked]> wrote:
>>=20
>>>> That is the point of the draft.  All of the uses of INFO
>> today have
>>>> alternatives that do not have the same problems.
>>>>=20
>>>> In fact, I am really thinking the draft should point out
>> the use of
>>>> INFO for SIP-T is also incorrect.  SIP-T should use a control=20
>>>> channel, not the "SIP"
>>>> channel, for transporting proprietary signaling.  The only thing=20
>>>> SIP-T does is re-create TCP over SIP.  Not a very useful
>> use of SIP.
>>>=20
>>> I don't think that's a fair assessment of SIP-T, since you
>> seem to be
>>> ignoring the fact that SIP-T also (primarily) uses other
>> methods than
>>> INFO.
>>>=20
>>> The encapsulation of 'proprietary' signaling is done to convey=20
>>> information that cannot currently be conveyed in pure SIP.
>> But other
>>> than that, within the VoIP domain the regular SIP dialog
>> model is used
>>> to establish and tear down sessions. SIP headers take
>> precedence over
>>> the contents of the ISUP/Q.931 message, so the 'tunneled'
>> message is
>>> only used to fill in some blanks at the receiving end. For the most=20
>>> part proxies and even user agents can safely ignore the
>> message body
>>> and still participate in the SIP dialog.
>>>=20
>>> Some ISUP/Q.931 messages arrive at a stage in the session where SIP=20
>>> doesn't define any interaction between UAs, so currently
>> INFO is used
>>> as a tunnel. If you believe it should be replaced by something less=20
>>> ambiguous, that won't be abused outside the scope of SIP-T the same=20
>>> way INFO is today, I guess that's fair enough. But saying
>> that SIP-T
>>> should use TCP tunnels instead seems a bit harsh.
>>>=20
>>> Bram
>>>=20
>>=20
>>=20
>>=20
>> Notice:  This email message, together with any attachments, may=20
>> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and =20
>> affiliated entities,  that may be confidential,  proprietary, =20
>> copyrighted  and/or legally privileged, and is intended solely for=20
>> the use of the individual or entity named in this message. If you are

>> not f.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1383148730=="
Errors-To: [email-masked]

--===============1383148730==
Content-Type: multipart/alternative; 
	boundary="----=_Part_26783_31114857.1189090016770"

------=_Part_26783_31114857.1189090016770
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thank you, it does shed a little bit of light.  I had since changed the API
to use the previous value of the Expires header rather than insert the
parameter from the notify.  It seems whoever wrote that section of the API
also misunderstood the RFC.

Thanks again.

On 9/6/07, Michael Procter <[email-masked]> wrote:
> I think you have misunderstood RFC3265 in this matter.  If the client
> receives a NOTIFY with "Expires: 5", it should infer that the current
> subscription will expire in 5 seconds.  If it wishes to extend the
> subscription, it will need to send a reSUBSCRIBE.  It does not need to
> resubscribe with an expiry of 5 seconds!  Instead, it may choose a different
> one (whatever worked the first time would be a good choice).
>

------=_Part_26783_31114857.1189090016770
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thank you, it does shed a little bit of light.&nbsp; I had since changed the API to use the previous value of the Expires header rather than insert the parameter from the notify.&nbsp; It seems whoever wrote that section of the API also misunderstood the RFC.
<br><br>Thanks again.<br><br><div><span class="gmail_quote">On 9/6/07, <b class="gmail_sendername">Michael Procter</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Nicholas,<br><br>[RFC3265 extracts]<br>&gt; If the value of the &quot;Subscription-State&quot; header is &quot;active&quot; or<br>&gt; &quot;pending&quot;, the notifier SHOULD also include in the &quot;Subscription-<br>
&gt; State&quot; header an &quot;expires&quot; parameter which indicates the time<br>&gt; remaining on the subscription.<br>&gt; ..the intended recipient, and have received this message in error,=20
>> please immediately return this by email and then delete it.
>>=20
>=20

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

---

From: "Nicholas Mattiello" <[email-masked]>
Date: Thu, 6 Sep 2007 10:46:56 -0400

<br>&gt; the subscription has been accepted and (in general) has been<br>&gt; authorized.&nbsp;&nbsp;If the header also contains an &quot;expires&quot; parameter, the<br>&gt; subscriber SHOULD take it as the authoritative subscription duration
<br>&gt; and adjust accordingly.<br><br>&gt; So if there is 5 seconds left on a subscription, and a client receives<br>&gt; a NOTIFY, the client changes the Expires of any subsequent SUBSCRIBEs<br>&gt; for that event to 5 seconds, and requires a refresh at less than 5
<br>&gt; second intervals. The longer the client runs, the smaller this value<br>&gt; will become.<br><br>I think you have misunderstood RFC3265 in this matter.&nbsp;&nbsp;If the client receives a NOTIFY with &quot;Expires: 5&quot;, it should infer that the current subscription will expire in 5 seconds.&nbsp;&nbsp;If it wishes to extend the subscription, it will need to send a reSUBSCRIBE.&nbsp;&nbsp;It does not need to resubscribe with an expiry of 5 seconds!&nbsp;&nbsp;Instead, it may choose a different one (whatever worked the first time would be a good choice).
<br><br>So, a typical flow could look something like this:<br><br>SUBSCRIBE (Expires:180) ---&gt;&nbsp;&nbsp;&nbsp;&nbsp;# Initial subscribe requesting 180 secs<br>&lt;--- 200<br>&lt;--- NOTIFY (Expires: 180)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Note need to resubscribe in 180 secs
<br>200 ---&gt;<br><br>(time passes (137 secs), something happens)<br>&lt;--- NOTIFY (Expires: 43)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # Note need to resubscribe in 43 secs<br>200 ---&gt;<br><br>(another 23 seconds pass, client decides to extend subscription, as only
<br>20 seconds remain)<br>SUBSCRIBE (Expires: 180) ---&gt;<br>&lt;--- 200<br>&lt;--- NOTIFY (Expires: 180)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Subscription extended for 3 mins<br>200 ---&gt;<br><br>I hope this clarifies things,<br><br>Michael<br></blockquote>
</div><br>

------=_Part_26783_31114857.1189090016770--

--===============1383148730==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1383148730==--

f.org>

Thanks again.

Thank you, it does shed a little bit of light.&nbsp; I had since changed the API to use the previous value of the Expires header rather than insert the parameter from the notify.&nbsp; It seems whoever wrote that section of the API also misunderstood the RFC.
<br><br>Thanks again.<br><br><div><span class="gmail_quote">On 9/6/07, <b class="gmail_sendername">Michael Procter</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Nicholas,<br><br>[RFC3265 extracts]<br>&gt; If the value of the &quot;Subscription-State&quot; header is &quot;active&quot; or<br>&gt; &quot;pending&quot;, the notifier SHOULD also include in the &quot;Subscription-<br>
&gt; State&quot; header an &quot;expires&quot; parameter which indicates the time<br>&gt; remaining on the subscription.<br>&gt; ...<br>&gt; If the &quot;Subscription-State&quot; header value is &quot;active&quot;, it means that
<br>&gt; the subscription has been accepted and (in general) has been<br>&gt; authorized.&nbsp;&nbsp;If the header also contains an &quot;expires&quot; parameter, the<br>&gt; subscriber SHOULD take it as the authoritative subscription duration
<br>&gt; and adjust accordingly.<br><br>&gt; So if there is 5 seconds left on a subscription, and a client receives<br>&gt; a NOTIFY, the client changes the Expires of any subsequent SUBSCRIBEs<br>&gt; for that event to 5 seconds, and requires a refresh at less than 5
<br>&gt; second intervals. The longer the client runs, the smaller this value<br>&gt; will become.<br><br>I think you have misunderstood RFC3265 in this matter.&nbsp;&nbsp;If the client receives a NOTIFY with &quot;Expires: 5&quot;, it should infer that the current subscription will expire in 5 seconds.&nbsp;&nbsp;If it wishes to extend the subscription, it will need to send a reSUBSCRIBE.&nbsp;&nbsp;It does not need to resubscribe with an expiry of 5 seconds!&nbsp;&nbsp;Instead, it may choose a different one (whatever worked the first time would be a good choice).
<br><br>So, a typical flow could look something like this:<br><br>SUBSCRIBE (Expires:180) ---&gt;&nbsp;&nbsp;&nbsp;&nbsp;# Initial subscribe requesting 180 secs<br>&lt;--- 200<br>&lt;--- NOTIFY (Expires: 180)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Note need to resubscribe in 180 secs
<br>200 ---&gt;<br><br>(time passes (137 secs), something happens)<br>&lt;--- NOTIFY (Expires: 43)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # Note need to resubscribe in 43 secs<br>200 ---&gt;<br><br>(another 23 seconds pass, client decides to extend subscription, as only
<br>20 seconds remain)<br>SUBSCRIBE (Expires: 180) ---&gt;<br>&lt;--- 200<br>&lt;--- NOTIFY (Expires: 180)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Subscription extended for 3 mins<br>200 ---&gt;<br><br>I hope this clarifies things,<br><br>Michael<br></blockquote>
</div><br>

------=_Part_26783_31114857.1189090016770--

--===============1383148730==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1383148730==--