Subject: RE: [Sipping] Comments on draft-ietf-sipping-conference-package-10.txt

From: "Orit Levin" <[email-masked]>
Date: Thu, 14 Apr 2005 09:57:21 -0700

> 
> We have an identified need, and we should collapse this work and the
> pidf/xcap work, go back and look at dialog, and define a single way to
do
> partial notification in SIP events.
> 
Yes, sure.
- Let's deprecate the dialog package
- Let's put the conferencing package on hold
- Let's invent the partial notifications all over again - not
necessarily simpler or more efficient, but definitely much smarter

And above all - let's hope that the industry will wait for us.

Orit.

_______________________________________________
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: "Shimon Hason" <[email-masked]>
Date: Thu, 14 Apr 2005 22:23:24 +0300

Hi,
 
IMHO maximum-user-count is not only a matter of resources consumption. We would like to limit the conference size for policy/licensing issues; also, we would like to give heads up for the conference participant/operator/moderator, etc. (e.g. why should I invite 10 poeple to a chat which was limited to 5). 
 
I beleive we should leave the definition as is (maybe some additional text should be added to make things clearer - such as what counts as a user, as Brian raised).
 
Thanks,
Shimon Hason

________________________________

From: [email-masked] on behalf of Brian Rosen
Sent: Thu 4/14/2005 8:14 PM
To: 'Orit Levin'; 'Shimon Nurick'; [email-masked]
Subject: RE: [Sipping] Comments on draft-ietf-sipping-conference-package-10.txt

I don't agree that it works, but if you insist on it, then you at least have
to do a better job of defining it.

The two questions I asked were: does it include streaming participants,
and does it include robo-participants

And while we are at it, does the users list include streaming participants
and robo-participants?  Whatever the answer is, say it in the text.

Brian

-----Original Message-----
From: Orit Levin [mailto:[email-masked]]
Sent: Thursday, April 14, 2005 12:40 PM
To: Brian Rosen; Shimon Nurick; [email-masked]
Subject: RE: [Sipping] Comments on
draft-ietf-sipping-conference-package-10.txt

This single scalar allows for a simple representation of the average
resource consumption by a single typical participant in the particular
conference (which is potentially described with additional granularity
by the rest of the package definitions).

Now seriously, more than s single conferencing implementer expressed the
strong need for this variable. If to your system it is useless, don't
specify it.

Orit.

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, April 14, 2005 9:23 AM
> To: 'Shimon Nurick'; [email-masked]
> Cc: Orit Levin
> Subject: RE: [Sipping] Comments on
draft-ietf-sipping-conference-package-
> 10.txt
>
> Fine.  The real limit in most systems is CPU/DSP MIPs and aggregate
> bandwidth.  It's not the number of people.
>
> Give me a definition that everyone can get behind.
> Does it reduce to a single scalar?  I suspect not.
>
> For example, you may be able to handle more audio only participants
that
> audio+video participants.  You may be able to handle a very large
number
> of
> streaming participants, but a much smaller number of interactive
> participants.  Most systems don't count robo attendees (a recorder for
> example), is it in this definition?
>
> The package introduces all of the complexity of audio, video and
> streaming,
> but leaves this value as a single undefined scalar based on people
count.
> It's not that easy.
>
> Brian
>
> -----Original Message-----
> From: Shimon Nurick [mailto:[email-masked]]
> Sent: Thursday, April 14, 2005 11:56 AM
> To: [email-masked]
> Cc: Orit Levin; Brian Rosen
> Subject: RE: [Sipping] Comments on
> draft-ietf-sipping-conference-package-10.txt
>
>  13. Section 5.2.3 "maximum-user-count"
> <rant>We have never defined what this means.  We have never come up
with
> a reason to have it.  We are blindly copying a mechanism that TDM
> systems use without any reflection on whether that works in this
domain.
> For example, does the number of clients of the streaming service
> count?</rant>
>
> We would like to limit a conference size, so its dynamic expansion is
> limited and can't occupy unlimited resources (DSP on the focus, BW on
> the NW etc.)
>
> Shimon
>
>
>
>

---

From: "Shimon Nurick" <[email-masked]>
Date: Thu, 14 Apr 2005 23:14:23 +0300

This is a user "understandable" limit - he can't invite more then X
parties to his conference.
It isn't that simple to calculate the system resources - but this is not
the purpose -
The purpose here is that a single conference can't "abuse" and block the
system by expanding to the system limits.
You can look at this as a kind of license, or level of service that is
provided to the user.

Shimon 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 14 April, 2005 19:23
To: Shimon Nurick; [email-masked]
Cc: 'Orit Levin'
Subject: RE: [Sipping] Comments on

For example, you may be able to handle more audio only participants that
audio+video participants.  You may be able to handle a very large number

audio+of

The package introduces all of the complexity of audio, video and
streaming, but leaves this value as a single undefined scalar based on
people count.
It's not that easy.

Brian

-----Original Message-----
From: Shimon Nurick [mailto:[email-masked]]
Sent: Thursday, April 14, 2005 11:56 AM
To: [email-masked]
Cc: Orit Levin; Brian Rosen
Subject: RE: [Sipping] Comments on

 13. Section 5.2.3 "maximum-user-count"
<rant>We have never defined what this means.  We have never come up with
a reason to have it.  We are blindly copying a mechanism that TDM
systems use without any reflection on whether that works in this domain.
For example, does the number of clients of the streaming service
count?</rant>

Shimon

---

From: [email-masked]
Date: Mon, 18 Apr 2005 12:09:04 +0300

Hi, 

I think this issue is being discussed in this I-D:

http://www.ietf.org/internet-drafts/draft-urpalainen-simple-xcap-patch-o
ps-00.txt

As far as I know update should be coming out soon.

- Mikko

>It used to be that we believed that the "S" in SIP implied 
>"Simple", as in not complex.  We gave up on that long ago, but 
>there is a principal here.
>We have several packages that have needed partial 
>notification, and so far, all of them have defined their 
>mechanism inside the package definition, and no two are 
>exactly alike (allowing that dialog and conference are very similar).
>
>This is bad engineering design, and we're allowing it.
>It is unnecessarily increasing the complexity of the protocol 
>and all implementations of these packages.
>
>We have an identified need, and we should collapse this work 
>and the pidf/xcap work, go back and look at dialog, and define 
>a single way to do partial notification in SIP events.
>
>Brian
>
>Sent: Thursday, April 14, 2005 10:43 AM
>To: Dean Willis; Brian Rosen; [email-masked]
>I will reply to Brian's "small issues" in a separate mail. (I 
>promise that it will take me less than two weeks, so, Brian, 
>please, don't disappear from the list for too long :-)
>
>Regarding the "big partial notification issue":
>
>First, indeed, the dialog package uses the same (as the conferencing
>package) original to SIPPING "classic" partial notification mechanism.
>This mechanism is built into an application XML schema by 
>defining the "state" attribute to selected elements.
>
>Secondly, please, let's keep the two important (but loosely coupled to
>conferencing) questions:
>(1) Why did SIMPLE take a separate route and define its own 
>different from SIPPING (but still application specific) 
>partial notification mechanism?
>(2) Is some XCAP or general DIFF mechanism a better generic 
>way to go for all SIPPING and SIMPLE packages in the future?
>separately from the basic conference package discussion.
>
>I would like to stress out that a "conference package" 
>mechanism without partial notifications is useless due to the 
>conference application nature, which by definition involves 
>multiple asynchronous participants and, in many cases, a large 
>number of these participants.
>
>The Conference Package authors and the chairs just recently 
>discussed this issue and agreed that the solution captured in 
>-10 is the most (and probably the only) practical one at this 
>point of time: 
>"This specification defines a basic partial notifications 
>mechanism by using a 'state' attribute [as described below].  
>This mechanism MUST be supported by all subscribing clients.  
>Additional general partial notifications mechanisms can be 
>defined and applied to this package in the future."
>
>Thanks,
>Orit.
>
>
>
>> From: Dean Willis [mailto:[email-masked]]
>> Sent: Wednesday, April 13, 2005 11:32 PM
>> To: Brian Rosen
>> Cc: Orit Levin; [email-masked]
>> Subject: Re: [Sipping] Comments on
>> On Apr 13, 2005, at 9:02 PM, Brian Rosen wrote:
>> 
>> > I have reviewed this draft and have the following comments:
>> >
>> > First a large issue, and then a bunch of small ones.  The big one
>is: I
>> > wonder if it is appropriate for a specific package, like this one,
>to
>> > define
>> > a partial notification scheme.  Is that not a generalized problem?
>Do
>> > we
>> > want every package to define its own?  Is this particular model 
>> > peculiar to conference information?
>> > This something all of sipping, not just those interested in 
>> > conferencing should consider.
>> >
>> 
>> Doesn't this use the same mechanism as the dialog package, modulo a 
>> "delete" operation?
>> 
>> But, that question raised, I am getting a lot of questions from OMA 
>> relating to the differences in the partial notification models for 
>> presence and xcap. It looks like  we can send a whole PIDF 
>in presence 
>> NOTIFYs, and only a diff (or an indirect to a document that must be 
>> fetched via xcap) for xcap. There would be a benefit to a more 
>> consistent model here.
>> 
>> 
>> --
>> dean
>
>
>
>
>
>
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip