Subject: RE: [Sipping] Conference URIs and Caller Prefs

From: "Eric Burger" <[email-masked]>
Date: Thu, 8 Aug 2002 10:22:45 -0400

One thing I would like to point out is that the caller prefs scheme Alan
proposes, ";features=conference", is 100% compatible with, and is not broken
by, the "conf=" mechanism of netann.

The caller prefs concept relates to the registration for a single user such
that a proxy can determine where to route a call.  The user part of the URI
refers to the user, not the service.  The caller prefs part refers to a
possible location for the user, namely, in their conference.

The Basic Network Media Services with SIP (netann) concept relates to a
multi-function media server that offers a mixing service.  The media server
presents the mixing service to the network as a "conf" user.  Moreover,
there is no concept of a user residing at a media server.  That is why the
service indicator, "conf", is in the user part of the URI.

The reason I am commenting here is that this is an excellent example of how
netann neither changes SIP nor limits SIP.  In particular, if netann imposed
a name space on SIP, then one could argue that to address a given user's
conference service, you would have to user the netann convention.  For
example, "sip:conf=[email-masked]".  There is nothing to prevent Alan
to setup his user agent to accept such a URI.  However, there is nothing
that requires him to do that, either.

Saying that we should not standardize the basic services, as proposed in
netann, is like saying that we should not standardize caller preferences, as
proposed below.  If we did that, then we would NEVER be able to
interoperate.  There would be no way to know how to address the service.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Alan Johnston
Sent: Wednesday, July 17, 2002 8:42 AM
To: [email-masked]
Subject: [Sipping] Conference URIs and Caller Prefs

Here's a thought I've had relating to ad hoc conference URI identification
and caller prefs.

If we added a conference feature tag to the Caller Prefs draft,  it would
be useful for labeling a Contact for a conference URI as being a conference.

Specifically, along the same lines as feature=voicemail, define
feature=conference.  A conference bridge belonging to User B could be
registered with a Registrar that supports Caller Prefs by

   REGISTER sip:registrar.there.com
   Contact: sip:[email-masked];feature=conference

UserB could send a request to his/her ad hoc conference bridge by:

   INVITE sip:[email-masked]
   Accept-Contact: *;feature=conference

This has the advantage that the conference URI
sip:[email-masked] does not need to be provisioned into
UserB's UA, or discovered using some SIP or non-SIP method.

Also, if UserB is in an ad hoc conference and UserC knows this, UserC has a
choice of requesting to join the conference:

   INVITE sip:[email-masked]
   Accept-Contact: *;feature=conference

Or just to talk to UserB individually,  by sending the INVITE without using
the Accept-Contact header.

The Accept-Contact header could also be escaped into a Refer-To header
within a REFER for UserB to add a participant to a ad hoc conference, again
without any configuration or URI discovery mechanism.

Also, if UserB's UA is capable of performing local mixing, if User C was
added in a local conference with UserA, UserB could let UserA know that
they are now involved in a conference by adding the feature=conference tag
to its Contact header in a re-INVITE.

Thoughts?  Comments?

Thanks,
Alan Johnston
sip:[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

_______________________________________________
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