Subject: [sipcore] Questions to info events draft

From: Linyi Tian <[email-masked]>
Date: Thu, 17 Sep 2009 10:24:40 +0800

Hi, All

In section 7.8 it talks about the rate of info requests. It is not clear to
me where to specify the rate.
1. The first paragraph says that a Info package MUST define a requirement
for the maximum rate. Does it mean the rate will be specified in the IANA
registration? Or does it mean the INFO body(MIME) should include a parameter
for the rate?
2. The second paragraph says that a package MUST define a throttle
mechanism. Does it means the INFO body (MIME) needs to specify the
mechanism?

7.8.  Rate of INFO Requests

   Each Info Package MUST define a requirement of MUST strength which
   defines an absolute maximum on the rate at which an Info Package of a
   given type can generate INFO messages by a UA in a session.

   If possible, a package MUST define a throttle mechanism that allows
   UAs to further limit the rate of INFO messages.

Cheers,
Linyi

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 17 Sep 2009 00:47:03 -0400

I think each INFO event package will specify the rate of requests,
whether there should be one INFO for each state change associated with
that event or if that information can be buffered and sent one shot.
 
Sanjay

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Linyi Tian
	Sent: Thursday, September 17, 2009 7:55 AM
	To: [email-masked]
	Subject: [sipcore] Questions to info events draft

	Hi, All
	
	In section 7.8 it talks about the rate of info requests. It is
not clear to me where to specify the rate.
	1. The first paragraph says that a Info package MUST define a
requirement for the maximum rate. Does it mean the rate will be
specified in the IANA registration? Or does it mean the INFO body(MIME)
should include a parameter for the rate?
	2. The second paragraph says that a package MUST define a
throttle mechanism. Does it means the INFO body (MIME) needs to specify
the mechanism?

	   Each Info Package MUST define a requirement of MUST strength
which
	   defines an absolute maximum on the rate at which an Info
Package of a
	   given type can generate INFO messages by a UA in a session.
	
	   If possible, a package MUST define a throttle mechanism that
allows
	   UAs to further limit the rate of INFO messages.
	
	Cheers,
	Linyi

---

From: Linyi Tian <[email-masked]>
Date: Thu, 17 Sep 2009 13:14:34 +0800

Hi, Sanjay

Thank you for your feedback.

Does It mean that In the MIME body there should be one or more elements
Indicates the rate? From the draft Itself It Is not clear to me how this
will be done. Should we clarify this In the section 7.8?

Cheers,
Linyi

On 09-9-17 下午12:47, "Sanjay Sinha (sanjsinh)" <[email-masked]> wrote:

> I think each INFO event package will specify the rate of requests, whether
> there should be one INFO for each state change associated with that event or
> if that information can be buffered and sent one shot.
>  
> Sanjay
> 
>>  
>>  
>> 
>>  From: [email-masked]  [mailto:[email-masked]] On Behalf
>> Of Linyi  Tian
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Sep 2009 01:09:40 -0500

On Sep 17, 2009, at 12:14 AM, Linyi Tian wrote:

> Does It mean that In the MIME body there should be one or more  
> elements Indicates the rate? From the draft Itself It Is not clear  
> to me how this will be done. Should we clarify this In the section  
> 7.8?

I believe it means that the specification document (generally an RFC)  
that defines the INFO package describes the rate and limiter mechanism  
used with that INFO package. This rate is not encoded into the MIME;  
rather it is a characteristic of the INFO packagetype.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 17 Sep 2009 08:15:53 +0200

Hi,
 
A new version of the draft is on its way, which will address the WGLC comments we've received. I BELIEVE we had a similar comment earlier, so we are looking into it.
 
Regards,
 
Christer

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Linyi Tian
	Sent: 17. syyskuuta 2009 8:15
	To: Sanjay Sinha (sanjsinh); [email-masked]
	Subject: Re: [sipcore] Questions to info events draft

	Hi, Sanjay

	Does It mean that In the MIME body there should be one or more elements Indicates the rate? From the draft Itself It Is not clear to me how this will be done. Should we clarify this In the section 7.8?
	
	Cheers,
	Linyi

		I think each INFO event package will specify the rate of requests, whether there should be one INFO for each state change associated with that event or if that information can be buffered and sent one shot.
		
		Sanjay

			From: [email-masked]  [mailto:[email-masked]] On Behalf Of Linyi  Tian
			Sent: Thursday, September 17, 2009 7:55 AM
			To:  [email-masked]
			Subject: [sipcore] Questions to info events  draft

			Hi, All
			
			In section 7.8 it talks about the rate  of info requests. It is not clear to me where to specify the rate.
			1. The  first paragraph says that a Info package MUST define a requirement for the  maximum rate. Does it mean the rate will be specified in the IANA  registration? Or does it mean the INFO body(MIME) should include a parameter  for the rate?
			2. The second paragraph says that a package MUST define a  throttle mechanism. Does it means the INFO body (MIME) needs to specify the  mechanism?

			
			
			Cheers,
			Linyi

---

From: Linyi Tian <[email-masked]>
Date: Thu, 17 Sep 2009 14:24:42 +0800

Hi, Dean and Christer

Thanks a lot! This clarifies my doubt.

One more question, if we want to support suspend/resume capability for Info
event that would mean:
1. Send Update with "Recv-Info=nil" and empty body. -- suspend
2. Send Update with "Recv-Info=type" and empty body. -- resume

Is this understanding correct?

Cheers,
Linyi

---

From: Eric Burger <[email-masked]>
Date: Thu, 17 Sep 2009 06:51:24 -0400

That would work in all cases. However, remember there can be glare,  
and an INFO might be in flight from the far end.