Subject: [Sipping] Thoughts on the conf-info package

From: Rohan Mahy <[email-masked]>
Date: Tue, 21 May 2002 18:58:50 -0700 (Pacific Daylight Time)

Hi,

Below are some of my thoughts on the conf-info package and conferencing in
general.....

<shameless-diatribe>

** Discovering when the conf-info package is relevant

Imagine that I want to provide a roster of participants in adhoc
conferences as well as dial-in/dial-out conferences.  Many small adhoc
conferences (ex: 3-way calls) occur as a result of local mixing.    The
diagram below shows B performing local mixing between A, B, and C.  B
knows the complete list of participants in the conference, and can render
this roster locally, but A and C do not know about each other through SIP.

        A   C
         \ /
          B

A could subscribe to the conf-info package at B to find out about the
other participants involved in this small conference.  B would verify that
A is the same A that was involved in this dialog, and if this was an
ordinary conference, return the list of other participants: B and C.

How does A know to subscribe to this package?  The dialog between A and B
started out as an ordinary 2-party call.  It would be patently ridiculous
to subscribe to the conference info package for every two way call, so B
should provide some clue to A that more information is available.  A short
flow proposing this mechanism is below, where B REFERs A to SUBSCRIBE to
the conference-info package (at B), and B informs C that it is joining a
conference by including <sip:B;method=SUBSCRIBE?Event=conf-info> in a
Call-Info header.

    A               B              C

    |  stable call  |              |
    |<=============>|              |INVITE contains
    |               |-INV/200/ACK->|Call-Info header
    |               |              |
    |<=============>X<============>| start mixing
   *|<--REFER/202---|              |
    |---SUB/200---->|<---SUB/200---|
    |<--NOT/200-----|----NOT/200-->|
    | participants: | participants:|
    |   B, C        |  B, A        |
    |               |              |

   * Refer-To: <sip:B;method=SUBSCRIBE?Event=conf-info>

The rule for using these two mechanisms is simple.  If I know that I am
inviting someone to a conference and I want to reveal that information, I
include a Call-Info header which references a subscription to that
information.  If a dialog suddenly becomes involved in a conference and I
want to reveal that information, I REFER my peer to SUBSCRIBE to that
information.

Why is the Call-Info header relevant?  (There was previously some
discussion on the SIP list about the abuse of Call-Info carrying a SIP URI
for providing identity information).  Call-Info provides relevant yet
optional information about one side of a SIP dialog.  This seems like a
perfect description of the event package URI.  Certainly if this same
information (roster of participants) was provided as an http: URL nobody
would complain about this.

** How to authorize providing participant information

Lets assume that participants can have an (optional) attribute indicating
if they are "hidden" or "visible".  Lets assume that users assume the
default attributes unless they explicitly or implictly request otherwise.
A user who wants to remain hidden can also use a new Privacy attribute to
request that they are hidden from the participant list.  Of course, local
authorization policy could cause hidden participants to be seen by some
users (for example a moderator) despite this request.

** Using the conference-info package on cascaded conferences.

At the interim there was some discussion about adding a parameter to the
conference-info package to indicate that the subscriber wanted their
subscription to recurse through cascaded conferences.   Some folks thought
that it might be too hard to deal with the authorization issues in such an
environment.  I want to explain both the motivation for this feature and
why I think the feature is moderately easy to implement.  Two types of
cascaded conferences are shown below:

                     +-----+   +-----+
   A     C           |mixer|---|mixer|
    \   / \          +-----+   +-----+
     \ /   \          | | |     | | |
      B     D         A B C     D E F

Adam Roach suggested that if you were interested in the complete partipant
list of a cascaded conference, that you could issue several subscriptions.
This is overkill and a waste of resources as I will show below.

Consider the topology described below:

    +-------------+       +-------------+
    |     M1      |       |     M2      |
    |             |-------|             |
    |             |       |             |
    +-------------+       +-------------+
     |  |  |  |  |         |  |  |  |  |
     |  |  |  |  |         |  |  |  |  |
     |  |  |  |  |         |  |  |  |  |
     A  B  C  D  E         F  G  H  I  J
    /             \               \
   /               \               \
  X                 Y               Z

M1, M2, A, E, and H are all mixers in this example.

If each UA involved in the conference wanted to get an accurate list of
participants, you would end up with 105 subscriptions.  This is a classic
n-squared scaling problem (n=15, 15 * 14 / 2 = 105).  If recursion is
available automatically, only 18 subscriptions are necessary.  Just as in
the 2-party call case, it is not necessary for M1 to subscribe the
conf-info package at B, C, or D.  M2 doesn't need to subscribe to F, G, I,
or J.  Nor does A subscribe to X, E to Y, or H to Z.  (Each arrow in the
diagram below shows a subscription)

    +-------------+       +-------------+
    |     M1      |       |     M2      |
    |             |<----->|             |
    |             |       |             |
    +-------------+       +-------------+
     ^  ^  ^  ^  ^         ^  ^  ^  ^  ^
     |  |  |  |  |         |  |  |  |  |
     v  |  |  |  v         |  |  v  |  |
     A  B  C  D  E         F  G  H  I  J
     ^           ^               ^
     |           |               |
     X           Y               Z

The main criticism of recursion is that authorization filtering as you go
from mixer to mixer is difficult.  Fortunately the authorization burden of
generating a conf-info document only falls on entities which are mixers
[or who wish to assert special attributes about their participation
(robot, passive, or hidden).  Note that being hidden is different from
merely being a visible participant who happens to be anonymous.]

If M1 has appropriate moderator priviledges on M2, then M2 will include
the hidden participants that it is aware of to M2 (perhaps M1 and M2 are
operated by the same large company).  If M1 does not have appropriate
moderator priviledges on M2, then M2 will only provide a list of visible
participants.  Likewise, a mixer could use local policy to withhold
participant information implictly (the announcement robot participant
built into the system may be hidden implicitly, or H (a tech support call
center agent) may implicitly hide Z (the agent's supervisor who is
silently monitoring H's participation).

M2 may choose to use authentication information to gather more information
about the participants.  It might pass this information along unless
appropriate Privacy is requested.

</shameless-diatribe>

All this seems like reasonable mechanism and not too difficult to
implement to me.  Comments and flames welcome on this topic.

Also, re:

**  subscribing to conference creation and deletion

A UA in a network management, monitoring, or scheduling capacity, may be
interested only in a list of conferences on a particular conference
server, as opposed to complete participant information for a conference.
Should we solve this requirement using the same conf-info package using a
"filter" during the SUBSCRIBE, or a new event package, or not at all?

thanks,
-rohan

_______________________________________________
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: Anders Kristensen <[email-masked]>
Date: Wed, 22 May 2002 13:59:37 -0400

> want to reveal that information, I REFER my peer to SUBSCRIBE to that

Isn't it the case that if a UA is knowledgable about these conference 
notifications and becomes involved in a conference, it *will* want to 
receive notifications of membership changes etc. I'm wondering if it 
would be appropriate for the notifier to consider presence of some 
"conf-info" Supported token sufficient evidence for it to create an 
implicit subscription for the sender. Seems somewhat simpler.

Creation of the implicit subscription could be done even without a 
Supported tag. In worst case, an extra NOTIFY gets sent (and presumably 
rejected) per (direct) participant. Seems like a good tradeoff for the 
simplicity of the scheme.

Anders

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 22 May 2002 11:44:45 -0700 (Pacific Daylight Time)

> simplicity of the scheme.

so every time my (3-way mixing capable) SIP phone calls a similar phone
for an ordinary 2-party call (99% of the time), it gets an implicit
subscription to a conferencing package so that 1% of the time we can save
an explicit REFER and SUBSCRIBE?

thanks,
-rohan

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 22 May 2002 15:00:33 -0400

> an explicit REFER and SUBSCRIBE?

Yeah, so what? Isn't the implicit SUBSCRIBE effectively free? It's not 
like you have to SUBSCRIBE for BYEs either.  Also, the idea's not to 
save on bandwidth but to keep things simple.

Anders

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 22 May 2002 12:08:07 -0700 (Pacific Daylight Time)

> save on bandwidth but to keep things simple.

You need to generate a NOTIFY which is not free, and you need to keep
subscription state, which is cheap but not free.  I'm not convinced
using an implicit subscription is any easier, and it definitely doesn't
save bandwidth.  One thing your proposal does save on however is
notification latency.

thanks,
-rohan

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 22 May 2002 17:03:11 -0400

> save bandwidth.  One thing your proposal does save on however is

The SUBSCRIBE is potentially superfluous so it's not a given that 
implicit subscriptions won't save bandwidth, but as I said that's really 
not what concerns me.

I think it is simpler. It doesn't require UAs to understand REFER and 
Call-Info and this particular use of both. It seems a bit odd to me that 
the exact same information goes into two very different headers, 
Refer-To and Call-Info, depending on how the receiver gets to join the 
conference.

Anders

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 22 May 2002 14:52:06 -0700 (Pacific Daylight Time)

> Refer-To and Call-Info, depending on how the receiver gets to join the

(aside: to be good SIP citizens I think UAs will need to support REFER
anyway.)

Specifically, "the exact same information" you are talking about is a
SIP URI which specifies a request-URI, the SUBSCRIBE method, and a
specific event package.  The semantics are clear regardless how you
discovered this URI.  This URI could have been embedded in a web page and
the semantics are still the same.  It should be apparent to anyone that
you can put a URI in a Refer-To header, a Call-Info header, a Contact header,
the Request-URI, etc.  I understand that it takes a little getting used
to and might seem odd at first, but this is all very natural SIP behavior.

thanks,
-rohan

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 22 May 2002 18:32:20 -0400

> to and might seem odd at first, but this is all very natural SIP behavior.

So you're basically saying it doesn't matter which header this URI is 
carried in. You can put SIP URIs many different places, yes, but it 
usually means something different. Two different headers being used to 
the same effect is BAD.

Anders

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 22 May 2002 15:40:26 -0700 (Pacific Daylight Time)

> usually means something different. Two different headers being used to

You are confusing the sematics of the mechanism you use to get some
information, with the semantics of the information itself.  By analogy,
you can send me the same content by email or via an instant message.  The
semantics of the information is the same, but the semantics of the
two mechanisms are very different.

thanks,
-rohan

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 22 May 2002 19:07:02 -0400

> two mechanisms are very different.

I absolutely disagree. Well-defined SIP headers should imply semantics. 
They're not for general purpose transport of random information which 
you feel is somehow self identifying in terms of meaning.

I'll go a step further and suggest that any header that lends itself to 
that sort of hijacking may be too vaguely defined.

Anders