Subject: [Sipping] new version niemi-sipping-event-throttle-08

From: "Salvatore Loreto" <[email-masked]>
Date: Sun, 22 Feb 2009 19:11:47 +0100

Hi there,

I have submitted a new version of the event-throttle draft incorporating WG
feedback from past reviews and ML.

In the meanwhile it will appear on the IETF website here the link:
http://www.sloreto.com/tmp/draft-niemi-sipping-event-throttle-08.txt

cheers
Sal

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Wed, 25 Feb 2009 17:54:35 -0500

Sal,

Thanks for updating this draft. We are supportive of it moving forward
as a WG document.

Question: could the throttling request be made by an SBC, which could be
a single point of failure for Notifies being sent to multiple UEs.

Thanks,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Salvatore Loreto
Sent: Sunday, February 22, 2009 1:12 PM
To: [email-masked]
Subject: [Sipping] new version niemi-sipping-event-throttle-08

Hi there,

I have submitted a new version of the event-throttle draft incorporating
WG
feedback from past reviews and ML.

cheers
Sal
_______________________________________________
Sipping mailing list  https://www.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: Robert Sparks <[email-masked]>
Date: Wed, 25 Feb 2009 17:05:22 -0600

Geopriv's filter work is expecting throttle to proceed.

RjS

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Wed, 25 Feb 2009 18:21:14 -0500

Robert,

I agree the throttling is to proceed. 

My question is the throttling request being made by the SBC.

Martin

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Wednesday, February 25, 2009 6:05 PM
To: DOLLY, MARTIN C, ATTLABS
Cc: Salvatore Loreto; sipping LIST
Subject: Re: [Sipping] new version niemi-sipping-event-throttle-08

RjS

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 25 Feb 2009 19:46:06 -0500

In theory the UAC sets the requested rates, and the RLS server adjusts them based on its local policy.  But of course in reality an SBC could modify them, add them, or remove them on its way to the RLS server, to make the RLS server reduce or increase the rates.

-hadriel

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN
> C, ATTLABS
> Sent: Wednesday, February 25, 2009 6:21 PM
> To: Robert Sparks
> Cc: sipping LIST
> > Question: could the throttling request be made by an SBC,
> which could
> > be a single point of failure for Notifies being sent to
> multiple UEs.
> >
> > Thanks,
> >
> > Martin
> >
> > I have submitted a new version of the event-throttle draft
> > incorporating WG feedback from past reviews and ML.
> >
> > 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
> > 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
>
> Use [email-masked] for questions on current
> sip Use [email-masked] for new developments of core SIP
>

---

From: <[email-masked]>
Date: Fri, 27 Feb 2009 04:37:02 +0100

Agreed. In the draft we just describe the Subscriber & Notifier behaviors.
SBC intermediary can implement both Subscriber and Notifier procedures when it is inserted between the "real" Subscriber and Notifier.

Cheers,
Krisztian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Hadriel Kaplan
Sent: Wednesday, February 25, 2009 4:46 PM
To: DOLLY, MARTIN C, ATTLABS
Cc: sipping LIST
Subject: Re: [Sipping] new version niemi-sipping-event-throttle-08

-hadriel

> [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C,
> ATTLABS
_______________________________________________
Sipping mailing list  https://www.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