Subject: [Simple] Regarding throttle for notifications

From: kamal Rometra <[email-masked]>
Date: Thu, 22 Jul 2004 13:09:17 -0700 (PDT)

Hi,
 
I  have a clarification on the use of throttle in sending NOTIFY messages while using "eventlist" extension where user can subscribe to multiple presenties in a single Subscribe using Buddy List Uri.
 
Consider the case of a User subscribing to 100 presentites in one subscription using a SIP entity let's say "Buddy list" with a valid sip uri. Subscribing to this list will result in notification for status of all the 100 presentities. It may not be possible to send the status of all presentities in a single NOTIFY, so Notifier may have to send multiple NOTIFY messages in this case.
Does the Notifier need to use "throttle value" between 2 Notifications provided its sent by client in Event header parameter of SUBSCRIBE request ?
 
Once NOTIFYs are sent for initial SUBSCRIBE, and this subscription is for a longer duration, any changes in presentites's status will be sent as NOTIFY containing only updated status. 
If there are cases like notifier sends one NOTIFY with changed status of one presentity belonging to buddy list and detects change in status of another presentity of buddy list, he needs to send another NOTIFY. Can throttle value be used in this case too ??
 
Thanks

---------------------------------
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Aki Niemi <[email-masked]>
Date: Tue, 27 Jul 2004 15:16:29 +0300

Hi,

Inline.

On Thu, 2004-07-22 at 23:09, ext kamal Rometra wrote:
> Hi,
>  
> I  have a clarification on the use of throttle in sending NOTIFY
> messages while using "eventlist" extension where user can subscribe to
> multiple presenties in a single Subscribe using Buddy List Uri.
>  
> Consider the case of a User subscribing to 100 presentites in one
> subscription using a SIP entity let's say "Buddy list" with a valid
> sip uri. Subscribing to this list will result in notification for
> status of all the 100 presentities. It may not be possible to send the
> status of all presentities in a single NOTIFY, so Notifier may have to
> send multiple NOTIFY messages in this case.
> Does the Notifier need to use "throttle value" between 2 Notifications
> provided its sent by client in Event header parameter of SUBSCRIBE
> request ?

Yes, if one was provided by the subscriber and accepted by the notifier.
 
> Once NOTIFYs are sent for initial SUBSCRIBE, and this subscription is
> for a longer duration, any changes in presentites's status will be
> sent as NOTIFY containing only updated status. 
> If there are cases like notifier sends one NOTIFY with changed status
> of one presentity belonging to buddy list and detects change in status
> of another presentity of buddy list, he needs to send another NOTIFY.
> Can throttle value be used in this case too ??

The event list draft actually already talks about this. In order to rate
limit, the notifier may buffer resource state notifications and send
them in batches (i.e., a single RLMI body, and one or more individual
notifications of resource state sent in a multipart/related MIME body). 

The throttle value merely indicates the rate limit imposed by the
subscriber, which the notifier can use to implement this batching of
notifications.

Another thing to consider is whether the list notifications contain full
or partial state. As explained in the throttle draft [1], there are two
alternative buffering policies that the notifier can use, depending on
the notification type. If operating in full-state mode, each arriving
notification simply overwrites any previously buffered notifications. If
operating in partial-state mode, the state of the arriving notification
needs to be merged with any previously buffered notification.

Cheers,
Aki

[1]
http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttle-01.txt

>  
> Thanks
>  
>  
>  
> 
> 
> ______________________________________________________________________
> Do you Yahoo!?
> ______________________________________________________________________