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

From: Michael Hammer <[email-masked]>
Date: Thu, 23 May 2002 11:27:15 -0400

Rohan,

The notifications below protect the privacy of the person being conferenced 
in.  What about the privacy of the person in the original 2-party call?  In 
some countries, this could be considered an illegal wiretap if the mixing 
party does not disclose the addition of the third party to the original party.

In such legal domains, would the mixer automatically be require to assume 
the implicit subscription and send the notifies?  This is not required for 
every 2-party call, just when a mixing operation is done.

Does there need to be a mechanism by which party A can notify the party B 
in a 2-party call that no other parties are authorized to join?  Or should 
that be implicit?

I don't think this necessarily ruins the idea of an anonymous party.  In 
such cases as anonymous auctions, participants may be willing to join the 
conference knowing that all parties identities are not revealed.  Likewise, 
for some types of business transactions, the caller may accept if notified 
that others may be listening in, say for quality control purposes.  At 
least if they object they can always hang up.

Mike

At 06:58 PM 5/21/2002 -0700, Rohan Mahy wrote:

>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

_______________________________________________
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: "David R. Oran" <[email-masked]>
Date: Thu, 23 May 2002 11:42:25 -0400

--On Thursday, May 23, 2002 11:27 AM -0400 Michael Hammer 
<[email-masked]> wrote:

> Rohan,
>
> The notifications below protect the privacy of the person being
> conferenced in.  What about the privacy of the person in the original
> 2-party call?  In some countries, this could be considered an illegal
> wiretap if the mixing party does not disclose the addition of the third
> party to the original party.
>
So be it. It is completely and utterly fruitless to try to fix this with 
technical machinery. What about when my wife picks up an extnsion line in 
the house? What about holding up a second phone to the first while I dial 
someone? Sue me.

> the implicit subscription and send the notifies?  This is not required
> for every 2-party call, just when a mixing operation is done.
>
Is it legal to send the notifies under an encryption key for which you 
don't provide the decription key? Do I have to abort the conference leg if 
you don't ACK the notify. Get real.

> in a 2-party call that no other parties are authorized to join?  Or
> should that be implicit?
>
Define "authorized". By whom? How? Seems like it is up to party B to try to 
ascertain whether anyone has joined, not party A's responsibility to 
enforce the property. He may not even be able to if the call runs through a 
B2BUA, an anonymizer, or other media transformation engine not under his 
direct control (like a transcoder).

> conference knowing that all parties identities are not revealed.
> Likewise, for some types of business transactions, the caller may accept
> if notified that others may be listening in, say for quality control
> purposes.  At least if they object they can always hang up.
>
I think you have to assume there are lurkers unless you can enforce that 
there are not via cryptographic means. Trying to use the event machinery 
for such purposes is misguided and ultimately fruitless.

Dave.

>> Below are some of my thoughts on the conf-info package and conferencing
>> in general.....
>>
>> <shameless-diatribe>
>>
>> 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
>> 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-->|
>> discussion on the SIP list about the abuse of Call-Info carrying a SIP
>> URI for providing identity information).  Call-Info provides relevant yet
>> 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.
>>
>>     |             | -------|             |
>> 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)
>>
>>
>>
>>     |             | <----->|             |
>> 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.]
>>
>> 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>
>>

-----------------------------------------------------------
David R. Oran                   Phone/Fax: +1 978 264 2048
Cisco Systems                   VoIP: +1 408 571 4576
7 Ladyslipper Lane              Email: [email-masked]
Acton, MA 01720

---

From: Michael Hammer <[email-masked]>
Date: Thu, 23 May 2002 12:17:29 -0400

Dave,

I do not want to mix the legal mechanisms with the technical mechanisms.

My intent was not to provide a fool-proof technical mechanism for enforcing 
the law, but to provide the same level of information to party A as is 
being provided for party C.  If you say that one is fruitless, then why 
isn't the other also fruitless?  These are two sides of the same coin.  Why 
do you think those quality control messages are played?

The "authorized" may be the wrong word.  It is more of an indication of the 
wishes of the party who thinks he is in a 2-way call to the other party who 
may or may not respect those wishes.  Beyond that, the laws have their own 
mechanisms.

By the way, people have been sued and gone to jail.  Furthermore, I think 
this is on a slippery slope to having a B2BUA that can "conference-in" 
parties that neither party A nor B are aware of.

Mike

At 11:42 AM 5/23/2002 -0400, David R. Oran wrote:

>Define "authorized". By whom? How? Seems like it is up to party B to try 
>to ascertain whether anyone has joined, not party A's responsibility to 
>enforce the property. He may not even be able to if the call runs through 
>a B2BUA, an anonymizer, or other media transformation engine not under his

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 23 May 2002 11:03:27 -0700 (Pacific Daylight Time)

Hi,

> party does not disclose the addition of the third party to the original party.

While the feature described below doesn't meet the definition of a wiretap
from an IETF perspective (see the "Raven" decision in RFC 2804), we need
to document these privacy requirements and possibly include in our
requirements the technical possibility for UAs to comply with various
legal requirements.

> every 2-party call, just when a mixing operation is done.

I don't think this is required, but I would have to see a description of
the appropriate law.  It's possible in some juristictions that the mixer
needs to be configured to render some media into the conversation indicating
that a "conference" is in progress (for example, play a tone or
announcement).

> in a 2-party call that no other parties are authorized to join?  Or should

it seems useful to have an explicit way to request that.  Perhaps an new
Privacy token would solve this problem ( no-conf )?

> least if they object they can always hang up.

I agree.

thanks,
-rohan