Subject: [Sipping] Event throttles

From: Aki Niemi <[email-masked]>
Date: Tue, 21 Mar 2006 02:15:36 +0200

All,

I'd like to draw your attention to an update to an I-D:
http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttle-04.txt

The only change I made was to remove all of the definitions and
discussion of the Supported/Require tag.

Now, the only thing this draft defines is a new Event header field
parameter called "throttle", and explains how to use it.

This has been discussed to death in SIPPING, but at this point I'm not
interested in pushing it towards a WG item any longer. Instead, I was
thinking of requesting publication as an individual RFC, since people
have been asking me for it.

There is at least one existing implementation, in open source.

Cheers,
Aki

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

---

From: Avshalom Houri <[email-masked]>
Date: Tue, 21 Mar 2006 02:24:35 +0200

I think this is about time (or it was about time several IETFs before) to 
accept this as a WG document.
Throttling is quite required in the industry.

--Avshalom

Aki Niemi <[email-masked]> 
21/03/2006 02:15 AM

To
[email-masked]
cc

Subject
[Sipping] Event throttles

All,

Cheers,
Aki

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Tue, 21 Mar 2006 13:31:45 -0500

Aki, we currently have an implementation that uses this throttle
mechanism - implementing this is much simpler than adding support for
a new XML schema just for the sake of throttle, irrspective of how
much richer it may be, especially for handsets.

Anyway, since this topic has been beaten to death in terms of
technical completeness vs. practicality, no use bringing it up again
(even though I just did :-) )

Question for you: Why was supported/require removed ? We use this
mechanism to ensure that throttling is indeed supported or not.

regds
arjun

--
Arjun Roychowdhury

---

From: Aki Niemi <[email-masked]>
Date: Tue, 21 Mar 2006 21:07:56 +0200

> mechanism to ensure that throttling is indeed supported or not.

Due to comments I received in Paris, IIRC. The minutes said something of
a "hallway discussion" that had determined Require wasn't needed as it
didn't help. Same issue as with the norefersub stuff.

Personally, I don't care, since I don't see this really a make-or-brake
type feature. In most (all?) cases, the client would simply re-subscribe
without a throttle, if it received a 420. Does yours?

I can add it back in, if only not to break existing implementations. ;)

Cheers,
Aki

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Tue, 21 Mar 2006 15:32:31 -0500

Aki, 21.4.15 of 3261 says 420 is used if the server did not understand
a protocol extension specified in Proxy-Require or Require - so in the
case we remove Require:throttle, will 420 still be sent by the server
for the client to know it has to drop throttle ?

regds
arjun

--
Arjun Roychowdhury

---

From: Aki Niemi <[email-masked]>
Date: Tue, 21 Mar 2006 23:50:06 +0200

> for the client to know it has to drop throttle ?

No, without the Require tag, the server would simply ignore the
throttle. The client would notice throtlling isn't on, since there is no
"throttle" in the Subscription-State field of the NOTIFYs.

So all in all, if previously, the client would have re-subscribed
anyway, when it saw the 420, we actually make this work a little more
smoothly *without* the require mechanism.

Cheers,
Aki

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Tue, 21 Mar 2006 17:04:41 -0500

Aki, this is my understanding too (that 420 will not be sent)
In our case, it is a requirement that the subscription not succeed
unless it is sure that throttling is supported for that particular
service - this particular service may result in the phone receiving
several NOTIFY messages (burst) immediately after the subscription is
accepted which is a problem for the phones that specified throttle in
the first place. This also has implications on charging ... since the
subscription was accepted and the first information about the service
sent out by the NOTIFY to the UA, then the UA realizes that it did not
have throttle, and it should not have been subscribed in the first
place, it raises 'billing contentions'

Anyway, I don't really want to pose my special case as a reason for
the require: header - but would generally like to state that I think
it is better that we have a mechanism to deny the subscription at the
start, than accepting it at the server and then having the UA realize
that the throttle was not supported as a resultant NOTIFY and then
having to un-subscribe.

I don't understand your point about the client re/un subscribing on
seeing the 420 - if we remove require: then 420 never occurs.

regds
arjun

--
Arjun Roychowdhury

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 21 Mar 2006 23:24:26 +0100

Aki,

Perhaps you could consider specifying a caller preference feature tag for 
this (RFC3841), instead of / in addition to(?) Require.
A phone could then use Accept-Contact: 
*;+sip.event-throttle;explicit;require if it really wants NOTIFY if and only 
if event-throttle is supported

In addition, this would enable the network to select the appropriate AS to 
serve the SUBSCRIBE, as 3GPP would like to see...

Regards,

Jeroen

----- Original Message ----- 
From: "Arjun Roychowdhury" <[email-masked]>
To: "Aki Niemi" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 21, 2006 11:04 PM
Subject: Re: [Sipping] Event throttles

regds
arjun

--
Arjun Roychowdhury

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Mar 2006 17:55:21 -0500

What does this have to do with callerprefs? Is the goal to select a UA 
that supports event-throttle? If not then this isn't an appropriate use 
of callerprefs.

	Paul

Jeroen van Bemmel wrote:
> Aki,
> 
> Perhaps you could consider specifying a caller preference feature tag 
> for this (RFC3841), instead of / in addition to(?) Require.
> *;+sip.event-throttle;explicit;require if it really wants NOTIFY if and 
> only if event-throttle is supported
> 
> In addition, this would enable the network to select the appropriate AS 
> to serve the SUBSCRIBE, as 3GPP would like to see...
> 
> Regards,
> 
> Jeroen
> 
> ----- Original Message ----- From: "Arjun Roychowdhury" <[email-masked]>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 22 Mar 2006 00:21:13 +0100

Paul,

Sorry, I should have said "to select the appropriate ~Notifier~" ( Notifier 
= a user agent which generates NOTIFY requests for the purpose of notifying 
subscribers of the state of a resource, RFC3265 )

So the goal would be to select a notifier that supports event-throttle (and 
that notifier could be a RLS )

Jeroen

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "Arjun Roychowdhury" <[email-masked]>; "Aki Niemi" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, March 21, 2006 11:55 PM
Subject: Re: [Sipping] Event throttles

> that supports event-throttle? If not then this isn't an appropriate use of 
> callerprefs.
>
> Paul
>
> Jeroen van Bemmel wrote:
>> Aki,
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Mar 2006 18:27:25 -0500

Jeroen van Bemmel wrote:
> Paul,
> 
> Sorry, I should have said "to select the appropriate ~Notifier~" ( 
> Notifier = a user agent which generates NOTIFY requests for the purpose 
> of notifying subscribers of the state of a resource, RFC3265 )
> 
> So the goal would be to select a notifier that supports event-throttle 
> (and that notifier could be a RLS )

This only makes sense if there is a choice of notifier, with one that 
supports this and one that doesn't. Is that realistic?

	Paul

> Jeroen
> 
> ----- Original Message ----- From: "Paul Kyzivat" <[email-masked]>
>> that supports event-throttle? If not then this isn't an appropriate 
>> use of callerprefs.
>>
>> Paul
>>
>> Jeroen van Bemmel wrote:
>>
>>> Aki,
>>>
>>> *;+sip.event-throttle;explicit;require if it really wants NOTIFY if 
>>> and only if event-throttle is supported
>>>
>>> In addition, this would enable the network to select the appropriate 
>>> AS to serve the SUBSCRIBE, as 3GPP would like to see...
>>>
>>> Regards,
>>>
>>> Jeroen
>>>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 22 Mar 2006 00:43:59 +0100

Paul,

> supports this and one that doesn't. Is that realistic?

I would say yes, especially in multi-vendor environments. It could also make 
sense if there were only one notifier that does not support it: suppose the 
other side is a mobile device with limited resources; instead of waking it 
up, establishing a connection, and having it refuse the request with a 420, 
the proxy can filter the request at an earlier stage

In fact, I think there's something to say for a general import of all 
Require / Supported option tags into the callerprefs feature tags namespace. 
Such that you can expres preferences regarding supported features (e.g. 
endpoint that understands GRUUs, session timers, target-dialog, etc)

Jeroen

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 22 Mar 2006 09:08:49 -0500

This looks like a very useful addition, especially in limited-bandwidth
environments.

The I-D could be improved by adding a few examples.  Also, why not add a
"Working Code" section (as someone suggested a while back) describing
the open-source implemention that you mention?

As for Require/Supported/callerprefs:  In IMS/3GPP environments, there
seems to be an architectural tendency to (in effect) subdivide the
implementation of the UA for an AOR into a number of different
"application servers" -- INVITEs will get routed to an actual user
instrument, but NOTIFYs may get routed to a different subsystem entirely
(and possibly NOTIFYs for different events get routed to different
subsystems).  So it's best if an initial request manifests all the
requirements that will be placed on the interaction, rather than "if the
UA doesn't like answer it gets, it can terminate the dialog and try
again".  (More on this concept later.)

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Mar 2006 10:30:18 -0500

Jeroen van Bemmel wrote:
>>> Notifier = a user agent which generates NOTIFY requests for the 
>>> purpose of notifying subscribers of the state of a resource, RFC3265 )
>>>
>>> So the goal would be to select a notifier that supports 
>>> event-throttle (and that notifier could be a RLS )
>>
>>
> I would say yes, especially in multi-vendor environments.

I find this a bit far fetched. There would need be alternatives for the 
same target. Why/how would you have multiple servers for the same event 
for the same user?

> It could also 
> make sense if there were only one notifier that does not support it: 
> suppose the other side is a mobile device with limited resources; 
> instead of waking it up, establishing a connection, and having it refuse 
> the request with a 420, the proxy can filter the request at an earlier 
> stage

OK. This I understand, and it does seem an appropriate usage. You don't 
need any IMS filtering to do this. Instead, adjust the callerprefs to 
exclude any contact that doesn't have the throttle capability. (Rather 
than just prioritizing those that do support it over those that don't.)

> Require / Supported option tags into the callerprefs feature tags 

They are already in the namespace.

> Such that you can expres preferences regarding supported 
> features (e.g. endpoint that understands GRUUs, session timers, 
> target-dialog, etc)

There is however no automatic addition of capabilities based on the 
Supported header. They need to be added explicitly.

	Paul

>>>> What does this have to do with callerprefs? Is the goal to select a 
>>>> UA that supports event-throttle? If not then this isn't an 
>>>> appropriate use of callerprefs.
>>>>
>>>> Paul
>>>>
>>>> Jeroen van Bemmel wrote:
>>>>
>>>>> Aki,
>>>>>
>>>>> Perhaps you could consider specifying a caller preference feature 
>>>>> tag for this (RFC3841), instead of / in addition to(?) Require.
>>>>> In addition, this would enable the network to select the 
>>>>> appropriate AS to serve the SUBSCRIBE, as 3GPP would like to see...
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jeroen
>>>>>
>>>>>> > case we remove Require:throttle, will 420 still be sent by the > 
>>>>>> server