Subject: [Sipping] I-D ACTION:draft-victor-fullmesh-reqts-00.txt

From: [email-masked]
Date: Fri, 30 May 2003 07:13:49 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Requirements for Full-mesh Conference Model using 
                          Baseline Session Initiation Protocol
	Author(s)	: V. Paulsamy
	Filename	: draft-victor-fullmesh-reqts-00.txt
	Pages		: 7
	Date		: 2003-5-29
	
This memo enumerates requirements to realize full-mesh multiparty 
conferencing using baseline Session Initiation Protocol. Primary 
requirement is to advertise conference membersÆ addresses to new 
participants by concatenating multiple SDP session descriptions 
together. This particular requirement can solve several well-known 
problems, including disjoint meshes and race conditions, that are 
lingering in full-mesh conferencing for a while now.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-victor-fullmesh-reqts-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-victor-fullmesh-reqts-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-victor-fullmesh-reqts-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.

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 30 May 2003 14:51:55 -0400

> lingering in full-mesh conferencing for a while now.

I've read over this document; it's not really a requirements document, but
rather an argument for a particular approach to solving the problem.

It seems to imply that a minor protocol modification can be used to cause
baseline SIP to support full mesh conferences.  This clearly isn't true; end
points are going to have to negotiate support for it, since current end
points don't support it.  The idea of carrying end point identifiers in SDP
isn't necessarily a bad one, though.

I've been studying on full mesh conferencing, and after writing a simulator
for full mesh conferencing, using a simplified model of SIP, I think the
problem is rather more complicated than Victor realizes.

I've written a paper on it, which I'll be presenting at NOSSDAV next week.
It's available from my homepage --
<http://www1.cs.columbia.edu/~lennox/fullmesh.pdf>.  I think this would be
useful input to further discussion of full mesh conferencing, since I've
explained a lot of the relevant issues there rather better than I could do
it off the top of my head in e-mail.

-- 
Jonathan Lennox
[email-masked]
 
_______________________________________________
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: "Victor A Paulsamy" <[email-masked]>
Date: Fri, 30 May 2003 16:31:54 -0700

Inline ...

-----Original Message-----
>From: Jonathan Lennox [mailto:[email-masked]] 

>isn't necessarily a bad one, though.

This is a good point; I overlooked it. I'm inclined to solving it using a,
"session-level property attribute that applies to conference as a whole"
[from 2327]. It could be something like "a=playoutmix." This attribute needs
to be defined.

When "a=playoutmix" is present, it indicates that an end system supports
session-level mixing for play out and if absent, it is not supported. Hence,
to support full-mesh conferencing, both offer and answer must have
"a=playoutmix" attribute. 

When inviting a new entity into the conference, the offerer carries
session-level "a=playoutmix." The answer must contain "a=playoutmix" to
establish a dialog. Otherwise, it's ACKed and BYE is sent to terminate the
dialog (as usual). 

In the case of new ones joining the conference, if the incoming request
didn't have "a=playoutmix", a member can choose to discard it, silently.

Regards,

--victor