Conventional conferencing systems can be categorized into three different types, depending upon where media streams from participants are mixed.

Centralized Conferencing
A centralized conference [ SKBR03 ] bridge exists in a centralized model. The conference bridge is a conceptually simple device, consisting of a sip user agent to handle signaling, an rtp mixer to handle the media streams, a conference application layer for authentication, authorization & accounting services, and possibly conference control functions. Participants establish one-to-one media and signaling connections with the bridge. The bridge establishes voice paths between endpoints by collecting input signals and returning summed signals to conferees. Figure 1 illustrates how the media is mixed, (en/de)coded if necessary, and redistributed to participants.

Most current multimedia conferencing systems fall into this category. As permissions are controlled by an administrator (a.k.a. floor controller), end users don't have much access to configuration features.

Figure 1. Media Mixing in a Centralized Conferencing

Decentralized Conferencing
In a decentralized model, signaling control is centralized but media are exchanged between participants without going through a centralized bridge. There is no conference server or central point of control. Decentralized conferencing can be either of two types: full mesh or multicast.

Figure 2. Full Mesh Conferencing

A. Full Mesh Conferencing: A full-duplex media link (Figure 2) can be established between every pair of participants, resulting in a fully-connected mesh. Each endpoint transmits a copy of its stream to the N - 1 other endpoints, and receives N - 1 streams in return, on separate ports. Each pair of participants can communicate through any mutually supported codec type.

B. Multicast Conferencing: In a multicast conference, participants join a session by subscribing to a conference multicast address. This address might be advertised by one of the participants or a central server, or distributed to conferees prior to a conference. Each participant transmits a single copy of his stream to the conference multicast address, receiving N - 1 streams in return. From a receiver perspective, nothing changes from the full mesh arrangement except that the streams arrive on a single port. Multicast conferences can scale up to millions of users and do not really require any sip signaling. However, native multicast is not yet widely available.

To implement a flexible end-to-end conferencing system, the following considerations apply:

General requirements: A conference control framework should be scalable, extensible, generic, reliable, and secure. The scalability requirement means that the conference control framework must support reasonably large, geographically distributed, conferences. Moreover, it should be extensibly modular so that new components can be easily added or existing components changed. The conference control framework must also be generic so that it is not tied to any particular application. While conference control protocols are likely to consume significantly less bandwidth than media streams, some care needs to be taken for large conferences. Since the conference description and policy information can be massive, incremental updates are preferred to having to resend entire descriptions after each change. Similarly, changes in participant lists should be distributed as additions and removals. Also, not all participants care about the same level of detail; for example, some may only be interested when new members join or leave, but not when a participant adds herself to a floor queue. The importance of reliability and security is obvious.

Session establishment: A mechanism is required to establish connections among multiple participants, to manipulate and describe media “mixing” or “topology” for multiple media types (audio, video, text, position data, etc.). Sip is a good candidate for this purpose. Technical challenges involve flexibly defining the media and its transmission using the sdp (Session Description Protocol) [ HJ98 ].

Network resource management: Network resources are an important factor determining the communication quality of a conference, or “QoS” (quality of service). Conferencing on a best-effort internet is an on-going challenge. Large delay or jitter irritates participants and degrades conference quality. Considering network characteristics and available bandwidth, proper encoding/decoding schemes must be deployed.

Policy: A user rights database specifies the privileges of potential participants. User rights lists might include information about who can authorize the admission or expulsion of participants and who can act on floor control requests. Such functions are often combined into the role of a moderator, but a flexible system should allow them to be distributed among a set of participants.

Security and privacy: Unwelcome participants are excluded, so no unauthorized party may intrude upon or eavesdrop in a conference. A mechanism for membership and authorization control is required. The policy may describe which users are pre-authorized to join (“white list”), are explicitly forbidden from joining (“black list” or “block list”), or may join but in listen-only (“lurk”) mode. Since internet-based signaling protocols offer a variety of authentication mechanisms, a policy might also define at what strength each participant must authenticate. Unauthenticated users may be rejected or relegated to audience status.

Over the years, there have been many studies in the area of conference control [ KSW02, SNS01 ]. Most earlier works discuss only floor control aspects of conference control. Standardization efforts have met with limited success. H.323, developed by the itut, has several problems, including scalability issues due to insufficient T.124 database replication protocol and its limitation to binary asn.1 format (not text-based) protocol. Sip, in contrast, is a text-based protocol which can easily interact with other internet protocols. Sip is a signaling protocol for creating, modifying, and terminating multimedia sessions between multiple participants. Conferencing is possible using standard sip methods [ RSC02 ], allowing users to join and leave conferences and allowing invitation of other participants. However, sip by itself does not offer configurable conference policies, participant access lists, floor control, or user privilege levels. The sipping (Session Initiation Protocol Project Investigation) [ CBP08 ] wg is chartered to develop requirements for extensions to sip needed for multi-party applications. Xcon, working closely with sipping, focuses on development of a standardized suite of protocols for tightly coupled multimedia conferences [ JRPJ08 ].

A limitation of traditional conferencing systems is that a participant (not a conference administrator) can not control other participants' displays. Current conferencing systems generally do not have capability to select a subset of the conference participants to whom his media are sent or from whom streams are received. In this article, we introduce narrowcasting attributes to implement media restriction features within a sip framework.

Figure 3 shows a famous Japanese sculpture which is good example of narrowcasting attributes. Three monkeys: Mizaru (the monkey with eyes covered), Iwazaru (mouth covered), and Kikazaru (ears blocked) manifest the notion of limiting media vectors. Mizaru can not see (but can hear and speak); Iwazaru can not speak (but can see and hear); Kikazaru can not hear (but can speak and see).

Figure 3. Media Restriction (Narrowcasting Attribute)

In analogy to broad-, multi-, and any-casting, narrowcasting is a technique for limiting and focusing information streams, either sources or sinks (receivers). We employ the paradigm of multiple simultaneous chatspaces, each with several or many conversants and across which one has “multipresence,” permitted designation of multiple instances of one's “self.” The audio windows narrowcasting predicate calculus [ Coh00 ] is an formalization for such a permission scheme. In Table 1, narrowcasting audio attributes are listed and their characteristics explained. This article proposes deployment of these attributes within a sip framework.

Figure 4. A Three-Party Conference Model

Figure 4 shows the initial state of conference in which three participants- P₁, P₂ and P₃ -can talk to and hear each other. In other words, all the participants are in a fully connected media relationship. Our design will allow each user to send or receive data streams to/from a specific set of recipients in a session. For easier understanding, we consider only audio streams in this article. However, this design applies equally well to other media types, including video, text, and data (geographic location, for example).

3.1.1.  Source Functions: Mute and Select

A “mute” function is available in present-day conference systems. However, in most cases, a participant mutes herself by connecting the other conversant to “music on hold.” On-hold parties hear to the music, but no voice media is transmitted. In our definition, a user can explicitly mute another party.

In Table 2(a), three participants participate in a conference in which P₂ has been muted by P₁. This means P₁ doesn't want to hear P₂, but only P₃. Specifically,

• P₁ has a simplex (one-way) relationship with P₂, P₁ → P₂.

• P₁ has a duplex (two-way) media relationship with P₃, P₁ ↔ P₃.

• P₂ has a duplex media relationship with P₃, P₂ ↔ P₃.

As a result,

• When P₁ speaks, both P₂ and P₃ will hear.

• When P₂ speaks, only P₃ will hear (and NOT P₁).

• When P₃ speaks, both P₁ and P₂ will hear.

Equivalently for this simple example, P₃ might be selected by P₁. The connectivity matrix of the situation shown in Table 2(a) can be portrayed as

, 

representable in matrix form as

, 

where entry c_ij of the matrix represents connectivity of source i to sink j, and the main diagonal is populated by “don't care”s.

A scenario with four participants in a session is shown in Table 2(d). Here P₂ is selected by P₁, so P₁ can hear only P₂ but not others. Other participants can hear as usual. The connectivity of Table 2(d) is represented as

.

3.1.2.  Sink Functions: Deafen and Attend

Remote deafen is also available in full-functioned conferencing systems as “Listen-only mode.” In most cases, only an end-user or administrator may invoke this feature. In our definition, any user can control the media sent to or received from another.

Table 2. Narrowcasting Models

Control	Mute	Select	Deafen	Attend
P1 → P2
Situation	A participant wants to block media from a specific participant. In this scenario, P1 mutes P2.	A participant wants to receive media only from a particular participant. In this scenario, P1 selects P2.	A participant wants to block media to specific participant(s). In this scenario, P1 deafens P2.	A participant wants to send media to a specific participant. In this scenario, P1 attends P2
Result	P1 has only send-only relationship with P2. Other media vectors remain the same.	Only P1 ↔ P2 remains same. Other participants have receive-only media relationship withP1.	P1 has a receive-only media relationship with P2. Others remain the same.	Media from P1 only goes to P2. Others only send to P1 but cannot receive media from P1.

In Table 2(e), P₂ is deafend by P₁. This means P₁ doesn't want to send his voice to P₂ to hear. Specifically,

• P₁ has a simplex media relationship with P₂, P₁ ← P₂.

• P₁ has a duplex media relationship with P₃.

• P₂ has a duplex media relationship with P₃.

In this case:

• When P₁ speaks, P₃ will hear, but P₂ won't.

• When P₂ speaks, both P₁ and P₃ will hear.

• When P₃ speaks, both P₁ and P₂ will hear.

Equivalently, P₃ might be attended by P₁, so that only P₃ can hear P₁. P₁ could still hear all other streams. The connectivity matrix for Table 2(e) is

.

In Table 2(h), P₂ is attended by P₁. As a result only P₂ can hear from P₁. The connectivity matrix of this situation is

.

For egalitarian models with flat hierarchies, there is an asymmetry regarding both mute/select and deafen/attend: audibility of a source with respect to a sink is treated as a revocable privilege and a forsakable right. A sink can by default hear collocated sources, adjustable by narrowcasting commands. For example, if P₂ attends P₁ but P₁ has muted P₂, P₁ won't hear P₂. Further policy extensions will extend the permissions of such a protocol, including the ability to force audibility by overriding a source's mute or sink's deafen (which a parent might invoke when telechiding a distracted child: “How dare you mute me?!”). Consideration of such role-based issues will be the focus of future research.

Peers in a sip session are called user agents, and can function in the following roles:

User-Agent Client (uac) A client application that initiates a sip request.

User-Agent Server (uas) A server application that contacts the user when a sip request is received and returns a response on behalf of the user.

A sip end-point is capable of functioning as both a uac and a uas, but typically functions as only one or the other per session, depending upon the user agent that initiated the request.

Sip makes use of elements called proxy servers to help route requests to users' current locations, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. Sip also provides a registration function that allows users to upload their current locations (ip addresses) for use by proxy servers.

A typical hand-shaking exchange is shown in Figure 5, P₁ sending an invite request with media capabilities to P₂. A 100/trying and a 180/ringing message confirm that P₂ is being alerted. A 200/ok message (which might also contain the final session description message body, whose significance will be explained later) is sent once P₂ accepts the invite, notifying that a connection has been made. Upon receiving the 200/ok from P₂, P₁ sends an ack, usually triggered by a human user. A two-party duplex session is established at this point. The delay between the 180/ringing and 200/ok messages depends upon after how many rings the user accepts the call. Participants wishing to leave a session send a bye request within the session dialog [ ACA04 ].

Figure 5. Call Flow of a Typical, Simple sip Session

Sip signaling can be transported on either tcp or udp; a standard SIP entity must support both types [ RSC02 ]. For realizing narrowcasting attributes over sip, a client will follow the guideline of rfc 3261 Section 18: If a request is within 200 bytes of the path mtu (maximum transmission unit), or if it is larger than 1300 bytes, or the path mtu is unknown, the request must be sent using an rfc 2914 congestion-controlled transport protocol, such as tcp.

Figure 6. Conferencing Model

Narrowcasting attributes can be implemented in both centralized and decentralized conferences. This article focuses on a decentralized conference architecture, for which the media is mixed at each end-point. Figure 6 illustrates components of the conferencing system and their roles. We have extended the model being proposed by the ietf with narrowcasting attributes.

Focus: The focus is a sip user agent addressed by a conference uri (uniform resource identifier). It handles sip signaling between participants in a conference. The focus establishes media exchange among participants in a conference, and also implements conference policies. Its logical role is in analogy to that of a controller in a centrally signaling, distributed media architecture.

Participants: User agents are identified by a uri, communicating with each other after having been connected through the focus.

Conference notification service: The focus can act logically as a notifier [ Roa02 ], accepting subscriptions to the conference and notifying subscribers about changes to that state. The state includes the state maintained by the focus itself, the conference policy, and the media policy.

Conference policy server: A conference policy server stores and manipulates rules using an xcap (Extensible Markup Language Configuration Access Protocol) [ Ros07 ] database associated with participation in a conference. These rules include directives on the lifespan of the conference, who can and cannot join it, who can override the media policy, definitions of roles available in the conference, and the responsibilities associated with those roles.

Conference policy: The complete set of rules governing a particular conference is interpreted and enforced by the conference policy server.

Figure 7 illustrates a scenario in which P₁, P₂, and P₃ are in an rtp media session. If P₁ wants to mute P₂, P₁ sends a re-invite to P₂ with a modified sdp attribute, a=sendonly. P₂ then responds with 200/ok including a=recvonly along with other sdp attributes. As the negotiation determines to only send media from P₁ to P₂, a one-way rtp connection is established (P₁ → P₂). Thus is P₁ muted by P₂. The status of other participants (i.e., P₃ in this example) remains unchanged. An example of the re-invite/ok handshake in Figure 7 is shown below, where the first block of each log is the sip header and the second block is the sdp body.

Figure 7. Mute Call Flow

The 200/ok sequence looks like

In order to deafen P₂, P₁ sends a re-invite to P₂ with a modified sdp attribute, a=recvonly. P₂ then responds with 200/ok including a=sendonly along with other sdp attributes. As the negotiation determines only to transmit the media from P₂ to P₁, a simplex media connection is established (P₂ → P₁), thereby deafening P₂ by P₁.

Figure 8. Deafen Call Flow

The 200/ok sequence looks like

In order for P₁ to select P₂, P₁ sends a re-invite to all other participants except for P₂ with a modified sdp, a=sendonly, and other participants in the conference respond with 200/ok with a=recvonly along with other sdp attributes. A one-way media connection is established between P₁ and other participants excepting P₂, so P₂ is selected by P₁.

Figure 9. Select Call Flow

A 200/ok from P₃ returned to P₁ confirms the implicit mute.

As illustrated by Figure 10, P₁ sends a re-invite to all other participants (except for P₂) with a modified sdp attribute, a=recvonly, who respond with 200/ok including a=sendonly along with other sdp attributes. A one-way rtp media connection is thus established with other participants (excepting P2), so P₂ is attended by P₁.

Figure 10. Attend Call Flow

The 200/ok sequence looks like