Subject: [Sip] Comments and questions to draft-ietf-sip-uri-list-conferencing-01.txt

From: Linyi Tian <[email-masked]>
Date: Tue, 03 Jul 2007 17:21:01 +0800

Hi, all
(1) On section "5.  Conference Server Procedures"
Many conference servers have restriction to maximum number of attendees for conference. If the users of 'recipient-list' exceeds the limitation, what status code should be returned?

---------------------------------------
7.  Security Considerations
   This document discusses setup of SIP conferences using a request-contained URI-list.  Both conferencing and URI-lists services have specific security requirements which will be summarized here. Conferences generally have authorization rules about who can or cannot join a conference, what type of media can or cannot be used, etc.  This information is used by the focus to admit or deny participation in a conference.  It is RECOMMENDED that these types of authorization rules be used to provide security for a SIP conference.
----------------------------------------
(2) When and how the authorization rules are specified and applied to the conference? Before the conference creation seems not possible since Conf-URI is not assigned. If specified after the conference creation, it seems there is a risk after conf is created but rules are not ready. Some attendees may do something bad which is out of control during that period. 

Best Regards,
Linyi

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 17 Jul 2007 10:53:58 +0300

Hi Linyi,

> Many conference servers have restriction to maximum number of attendees 
> for conference. If the users of 'recipient-list' exceeds the limitation, 
> what status code should be returned?

I would return a 403 (Too many recipients).

>    This document discusses setup of SIP conferences using a 
> request-contained URI-list.  Both conferencing and URI-lists services 
> have specific security requirements which will be summarized here. 
> Conferences generally have authorization rules about who can or cannot 
> join a conference, what type of media can or cannot be used, etc.  This 
> information is used by the focus to admit or deny participation in a 
> conference.  It is RECOMMENDED that these types of authorization rules 
> be used to provide security for a SIP conference.
> (2) When and how the authorization rules are specified and applied to 
> the conference? Before the conference creation seems not possible since 
> Conf-URI is not assigned. If specified after the conference creation, it 
> seems there is a risk after conf is created but rules are not ready. 
> Some attendees may do something bad which is out of control during that 
> period.

They are applied at conference creation. The server receives the 
request, creates the conference with its rules, and only adds the 
participants in the list if those rules allow it to do it. This is 
already implemented in the OMA PoC (Push-to-talk over Cellular) service.

Thanks for your comments,

Gonzalo

---

From: Linyi Tian <[email-masked]>
Date: Thu, 19 Jul 2007 13:52:48 +0800

Hi, Gonzalo
But my question is when and how the rules are provided? For conferencing with pre-defined group the rules are typically specified by group owner (user). How about ad hoc conference?
I think currently in PoC ad hoc session, the rules are only local policy for PoC Server, but not provided by initiator, right? If there is a mean for initiator to manipulate rules after session is created, it seems there is a risk after conf is created but rules are not ready. Some attendees may do something bad which is out of control during that period. This is not expected by the initiator.
BR,
Linyi

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2007 3:54 PM
To: Linyi Tian
Cc: [email-masked]
Subject: Re: [Sip] Comments and questions todraft-ietf-sip-uri-list-conferencing-01.txt

Hi Linyi,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 19 Jul 2007 09:51:45 +0300

Hi,

the problem of doing many things in one SIP operation (i.e., in a SIP 
request) is that it is difficult to report errors if something goes wrong.

If you want to create an ad-hoc conference with rules that are different 
from the default ad-hoc conference, you can always use a different way 
to create the conference (i.e., without using URI lists; using a 
conference control protocol). URI lists are an optimization for the more 
typical use cases where session establishment should be very fast.

Cheers,

Gonzalo

---

From: Linyi Tian <[email-masked]>
Date: Thu, 19 Jul 2007 15:40:23 +0800

Hi, Gonzalo

> request) is that it is difficult to report errors if something goes wrong.
[Linyi] I think this problem might exist in URI List Conferencing. For example, too many recipients, URI format is invalid, etc. Do we need to consider these error conditions?

> typical use cases where session establishment should be very fast.
[Linyi] I agree fast is important. Beyond fast experience users also care about rules of a conference. And in some scenarios default rules obviously can not fulfill their expectation. For example, Initiator wants to provide some simple rules such as maximum attendee number, whether allow inviting new person, etc. I have to admit conf control protocol is too heavy to do that for ad hoc conference.

BR,
Linyi

Linyi Tian wrote:
c Hi, Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 19 Jul 2007 11:12:23 +0300

Hi,

>> the problem of doing many things in one SIP operation (i.e., in a 
>> SIP request) is that it is difficult to report errors if something 
>> goes wrong.

> [Linyi] I think this problem might exist in URI List Conferencing.
> For example, too many recipients, URI format is invalid, etc. Do we
> need to consider these error conditions?

Yes, it exists. That's why you want to use that mechanism only in the 
context of a well-defined service that is scoped well-enough (e.g., 
ad-hoc sessions in PoC) so that it does not create complex error 
situations when the mechanism is used.

Cheers,

Gonzalo