Subject: [XCON] RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt

From: "Even, Roni" <[email-masked]>
Date: Thu, 19 Apr 2007 12:06:00 +0300

Linyi,

I read the draft and have some comments about this direction.

1. It is an advantage in letting the invitee know the subject of the conference but this is true also for a point to point call. This is not unique to conference.

2. letting the invitee know who the other participants in the conference and the conference information is better served by the event package.

3. The issue in the URI list was to replace multiple refers with on message for inviting participants, this was part of a general mechanism. The issue of defining the conference parameters and controlling the conference was not considered in scope for this work.

4. "In current art there is no mechanism for new participants to be aware of the conference information they are being invited to." This is what the conference event package is used for. When you get an Invite with isfocus you can subscribe to the conference event package and get notification before joining.

5. REQ 1 is covered by XCON while REQ 2 is covered by the event package.

6. Section 4.1.2 adds data from the XCON data model including the start time yet the requirements talk about ad-hoc conferences. 

7. Using this method for controlling the conference by sending re-Invite will cause a lot of traffic through the proxies in the middle and that is why XCON is the way to do it.

To summarize - I can see some value in being able to send some information to the conference factory for the ad-hoc case. The information will include the required media and user count but this draft has a wider scope.

Roni Even 

> -----Original Message-----
> From: Linyi Tian [mailto:[email-masked]]
> Sent: Saturday, April 14, 2007 4:01 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-
> info-00.txt
> 
> Dear all
> 
> We just submitted an I-D to IETF regarding conference. Please kindly
> review and feel free to give us any comments. Thank you in advance.
> 
> Abstract & Requirements Anaylyze
>    This specification defines a mechanism that allows a UAC to provide a
>    conference server with the initial conference information and policy
>    using an INVITE-contained conference info.
> 
>    some environments have tough requirements regarding conference
>    establishment time.  This is true especially when a user wants to
>    create a conference in ad hoc manner.  In addition user may only want
>    very simple conference information and policy, for example the
>    subject and maximum numbers of participants, to be provided for an ad
>    hoc conference via only one operation.  In this case they rarely
>    desire to manipulate the conference policy during the conference.
> 
>    In current art there is no mechanism for new participants to be aware
>    of the conference information they are being invited to.  It causes
>    difficulty for them to decide whether to accept this invitation which
>    may not fall into their interest.
> 
> Best Regards,
> Linyi
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, April 14, 2007 3:50 AM
> To: [email-masked]
> Subject: I-D ACTION:draft-linyi-sipping-invite-with-conf-info-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Session Initiation Protocol (SIP) INVITE with
> Conference Info
> 	Author(s)	: L. Tian, Q. Sun
> 	Filename	: draft-linyi-sipping-invite-with-conf-info-00.txt
> 	Pages		: 24
> 	Date		: 2007-4-13
> 
> 
>    This specification defines a mechanism that allows a UAC to provide a
>    conference server with the initial conference information and policy
>    using an INVITE-contained conference info.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-linyi-sipping-invite-with-conf-
> info-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-linyi-sipping-invite-with-conf-info-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-linyi-sipping-invite-with-conf-info-
> 00.txt".
> 
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Linyi Tian <[email-masked]>
Date: Thu, 19 Apr 2007 20:51:33 +0300

Dear Roni Even

Thank your for your kind review and feedback. Some responses inline with mark [Linyi]:)

Best Regards,
Linyi

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Thursday, April 19, 2007 12:06 PM
To: Linyi Tian; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] FYI: I-DACTION:draft-linyi-sipping-invite-with-conf-info-00.txt

Linyi,

Linyi,

1. It is an advantage in letting the invitee know the subject of the conference but this is true also for a point to point call. This is not unique to conference.
[Linyi Tian] Good point! Do you mean that we need to use this mechanism for point to point scenario?

2. letting the invitee know who the other participants in the conference and the conference information is better served by the event package.
[Linyi Tian] Actually I guess in ad hoc manner the mechanism in this draft is more efficient.

3. The issue in the URI list was to replace multiple refers with on message for inviting participants, this was part of a general mechanism. The issue of defining the conference parameters and controlling the conference was not considered in scope for this work.
[Linyi Tian] Yes, that's true. But our draft does not have any intention to affect the URI-List work. Actually the mechanism in our draft can be used together with URI list. We just gave the example to address different scenarios: 1. without URI list; 2. with URI list. So when URI-List the conference server needs to perform more actions in addition to those defined in URI-List work.

4. "In current art there is no mechanism for new participants to be aware of the conference information they are being invited to." This is what the conference event package is used for. When you get an Invite with isfocus you can subscribe to the conference event package and get notification before joining.
[Linyi Tian] Good catch! I guess the sentence I wrote is not quite precise. I will modify it. 

5. REQ 1 is covered by XCON while REQ 2 is covered by the event package.
[Linyi Tian] According to the comments you mentioned, I will update REQs to better reflect our intention.

6. Section 4.1.2 adds data from the XCON data model including the start time yet the requirements talk about ad-hoc conferences. 
[Linyi Tian] Good catch. That is a mistake. Anyway I need to change something in next revision since that draft was updated.

7. Using this method for controlling the conference by sending re-Invite will cause a lot of traffic through the proxies in the middle and that is why XCON is the way to do it.
[Linyi Tian] Yes. What is stated in the draft is there is no semantics defined for re-INVITE. Actually it is recommended not using re-INVITE for controlling the conference in this draft. I can make it clearer.

To summarize - I can see some value in being able to send some information to the conference factory for the ad-hoc case. The information will include the required media and user count but this draft has a wider scope.
[Linyi Tian] I think in addition to subject and user count, we may find other information which could be useful as well. For example, <keyword> for search purpose, <service-uris> which provides complementary information such as URI for presentations:)

Roni Even