Subject: [Sipping] New draft about SIP conferencing avaiable

From: "Igor Miladinovic" <[email-masked]>
Date: Mon, 11 Feb 2002 12:41:24 +0100

Hi,

We have submitted a new draft to the IESG. It describes a SIP extension for
discovery of participants identities in a multiparty conference. The draft
is available at:

http://search.ietf.org/internet-drafts/draft-miladinovic-sip-multiparty-ext-
00.txt
or
http://www.ikn.tuwien.ac.at/ftw-a1/download.html

Your comments are welcome.

Regards,

Igor

--
DI Igor Miladinovic
Vienna University of Technology
Institute of Communication Networks
Call Control and Signaling
Favoritenstrasse 9/388
A-1040 Vienna, Austria

tel. +43-1-58801-38844
fax. +43-1-58801-38898
http://www.ikn.tuwien.ac.at

_______________________________________________
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: Sean Olson <[email-masked]>
Date: Mon, 11 Feb 2002 08:05:03 -0800 (PST)

How do you deal with the situation where a 
"conference" is identified by a r-uri and not by
a pre-existing dialog? (How do you know the 
appropriate Call-ID to place in the CONF request?)

/sean

--- Igor Miladinovic <[email-masked]>
> Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping

=====
Sean Olson <[email-masked]>

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

---

From: "Igor Miladinovic" <[email-masked]>
Date: Mon, 11 Feb 2002 17:45:52 +0100

> appropriate Call-ID to place in the CONF request?)

The conference server stores data (at least the sip-address) of each
participant in a conference, which is identified by a requestURI. This data
contains also the Call-ID of the corresponding dialog (determined by the
initial INVITE).

--
Igor

---

From: Sean Olson <[email-masked]>
Date: Mon, 11 Feb 2002 11:30:23 -0800 (PST)

What I was wondering was how someone would construct
the CONF request without knowing a priori the correct
Call-ID to use? I know how I would build this -- 
just use the Request-URI and ignore the
To/From/Call-ID. But the draft appears to imply
something different
when speaking of returning a 481 response. Perhaps
I misread that section or misunderstood your 
intentions(?)

/sean

wrote:
> > > discovery of participants identities in a
> multiparty
> > > conference. The draft
> > > is available at:
> > >
> > >
> >
>
http://search.ietf.org/internet-drafts/draft-miladinovic-sip-multi
> > party-ext-
> > > This list is for NEW development of the
> application
> > > of SIP
> > > Use [email-masked] for
> questions
> > > on current sip

=====

---

From: "Igor Miladinovic" <[email-masked]>
Date: Tue, 12 Feb 2002 10:38:16 +0100

> I misread that section or misunderstood your

Our intention is that a CONF request is created just like a BYE request.
Generally, in a conference each participant can send/receive a BYE request
every time. Because the BYE request presumes knowing of the From/To/Call-ID,
we suppose that it is also available for a CONF request. Do you agree with
this?

--
Igor

> > application of SIP

---

From: Sean Olson <[email-masked]>
Date: Tue, 12 Feb 2002 08:34:14 -0800 (PST)

It was my understanding that the CONF request
was designed to be used to determine the participants
of a conference call before joining that conference
call. That is, at the point in time at which you
construct the CONF request, you may not know the
Call-ID for the conference. But more importantly,
there probably will not be a unique Call-ID for
the conference as in the case of a conference
bridge. It's a small nit. You just need to be
careful in how you phrase the section describing
when a 481 is sent. 

On a different topic, it would be nice if there
was some generic request that could be sent to 
obtain information about an ongoing call. The 
participants of that call is just one such piece
of information. This kinda falls in line with the
call events package that was proposed to be used
with SUBSCRIBE/NOTIFY. By doing an immediate fetch
with that event package, you could get the 
participants without inventing a new method. And
of course, the type of information you could retrieve
could be expanded over time to include things like
who is the moderator of this call, how long has this
call been going on, etc.

cheers,
sean

wrote:
> > > participant in a conference, which is identified
> by
> > > a requestURI. This data
> > > > > We have submitted a new draft to the IESG.
> It
> > > > > describes a SIP extension for
> > > > > Use [email-masked] for new developments of
> core
> > > SIP
> > > >
> > > >
> > > > =====

=====

---

From: "Igor Miladinovic" <[email-masked]>
Date: Wed, 13 Feb 2002 11:35:16 +0100

Hi,

> bridge.

Actually, the purpose of the CONF request is to update participants lists in
a established conference. To determine the conference participants before
joining, we use the "participant" header in the INVITE request.

Regards,

Igor

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Wed, 13 Feb 2002 10:39:39 -0500

There is a generic way (i.e. independent of conference) to discover
parties in a call of a conference already defined in:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-call-package-00.txt
What functionality is missing from the call-package draft?

A draft also exists for providing operations to join the conference
with a specifed media topology:
http://search.ietf.org/internet-drafts/draft-mahy-sipping-join-and-fork-00.txt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Feb 2002 10:52:59 -0500

I was about to chime in with the same note....

it seems clear to me that there are several independent drafts working
on roughly the same problems. We also have some drafts on IM group
conferencing:

http://search.ietf.org/internet-drafts/draft-koskelainen-sip-group-00.txt

(although this focuses on somewhat different problems) and also:

http://search.ietf.org/internet-drafts/draft-khartabil-sip-conferencing-00.txt

which does look at participant identification.

I think a better approach is to understand the specific requirements,
especially as they apply to voice and IM session conferencing, and also
the IM page model, which I am beginning to think has subtlely different
requirements. 

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Igor Miladinovic" <[email-masked]>
Date: Thu, 14 Feb 2002 14:17:41 +0100

Hi,

> What functionality is missing from the call-package draft?

The conference-package can be used with SUBSCRIBE/NOTIFY instead of the CONF
method. However, the body containing the conference-package could be used in
a CONF request. This way, a UA that supports conferencing extension does not
need to support SUB/NOT extension. Besides that, the conferencing extension
provides the discovering of participant identities before the conference
starts (this information is carried in the participant header of an INVITE
request).

We think that this draft can be combined with our draft in order to
distribute not only participant identities, but also some additional
information (floor control policies, the replace URLs...).

> http://search.ietf.org/internet-drafts/draft-mahy-sipping-join-and

This draft deals with another conferencing issue. The discovering of
participants identities is not provided by this draft, but only how to join
to an existing conference (with knowledge of the corresponding Call-ID).

--
Igor