Subject: [Sipping] Conference URIs and Caller Prefs

From: Alan Johnston <[email-masked]>
Date: Wed, 17 Jul 2002 07:41:39 -0500

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Jul 2002 10:04:54 -0400

Alan,

I am having difficulty coming up with a case when this would be useful. My concerns are:

- requires the UA to register the conference
- once registered, calls might be accidentally sent to it
- doesn't work well for more that one conference at an AoR, 
  unless it really doesn't matter which one the caller gets.

To use this, the calling UA needs specific logic to insert the Accept-Contact header. If it has this, can't it also use other means (e.g. event packages) to discover the
(unregistered) conference?

There are of course lots of cases for registering a single conference. But in those cases I am coming up blank thinking of reasons why I would want multiple contacts in
that case, especially a mixture of conference and non-conference contacts.

Do you have an example in mind when this would be useful? Are you assuming that requests must be proxied through the AoR to be globally routable?

BTW, if you want a conference and only a conference, you'd better use:

    INVITE sip:[email-masked]
    Reject-Contact: *;feature="!conference"

	Paul

---

From: "Ranjit Avasarala" <[email-masked]>
Date: Thu, 18 Jul 2002 18:49:00 +0530

where can I find the draft on caller prefs? is the param feature= part of
any draft?

Ranjit
----- Original Message -----
From: Paul Kyzivat <[email-masked]>
To: Alan Johnston <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 17, 2002 7:34 PM
Subject: Re: [Sipping] Conference URIs and Caller Prefs

> To use this, the calling UA needs specific logic to insert the
Accept-Contact header. If it has this, can't it also use other means (e.g.
event packages) to discover the
> There are of course lots of cases for registering a single conference. But
in those cases I am coming up blank thinking of reasons why I would want
multiple contacts in
> Do you have an example in mind when this would be useful? Are you assuming
that requests must be proxied through the AoR to be globally routable?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Jul 2002 10:01:24 -0400

You can get the latest (draft-ietf-sip-callerprefs-06) from ietf.org. 

The use of feature= below is actually a typo. It ought to be "features=" which is defined in the draft.

	Paul