Subject: [p2p-sip] how to implement multi-party conference without a centralized mixer based on P2P SIP?

From: bellmark at huawei.com (liXiaowen 51208)
Date: Tue, 18 Apr 2006 10:07:41 +0800

hi folks,

Recently I have read one of henning's papers about P2P SIP,, in which he claim his project can support multi-party conference ,and a peer with strong capability can be selected to be the mixer in small scale conference .I'd like to say that it is not a p2p-sip-style implementation of the multiparty conference,because only one centralized "peer" is responsible for the task of mixing.what's more ,I've been puzzled by how a single mixer can handle the task of mixing in a large scale conference. can experts  here to give some explanation on this topic? 

Best Regards,

Mark

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Tue, 18 Apr 2006 10:51:42 -0400

Hi Mark,

liXiaowen 51208 wrote:
> hi folks,
> 
> Recently I have read one of henning's papers about P2P SIP,,
 > in which he claim his project can support multi-party conference
 > ,and a peer with strong capability can be selected to be the
 > mixer in small scale conference .I'd like to say that it is not
 > a p2p-sip-style implementation of the multiparty conference
 > because only one centralized "peer" is responsible for the task
 > of mixing.

I think the comparison you're making is to symmetric processing
of all audio on all hosts.

The idea of using a single peer as a mixer _is_ peer-to-peer,
in that no centralized infrastructure (server) is required to
perform the mixing operation. Mixing only occurs in end-peers.

> what's more ,I've been puzzled by how a single mixer
 > can handle the task of mixing in a large scale conference. can
 > experts  here to give some explanation on this topic?

The operation of choosing a single node to mix is different
in that of symmetric mixing, because the single mixer has to
tramsmit the entire stream to each of its peers.
The symmetric mixers need to have communications paths
between themselves and every other peer. The members of the
conference do not hear the same conversation (due to timing
and synchronization issues).

For the example, I'm using a fixed width font:

Symmetric Case

+--+     +--+
|  |<----|  |
|A |---->|B |
+--+     +--+
  |^\^   7/|^
  || \\ // ||
  ||  \X/  ||
  ||  /X\  ||
  V| // \\ V|
+--+L   V+--+
|  |<----|  |
|C |---->|D |
+--+     +--+

Please replace all V's, 7's, L's and ^'s as arrow heads

In this case, each node requires N-1 transmission links
to its neighbours, for a total of N(N-1)/2 bidirectional
links in the mixing network.

These have to be maintained for whenever that peer or the
other speaks, regardless of whether A is the predominant
speaker. All nodes only transmit their own stream.  The
individual transmissions will be received at different times
by other recipients.

+--+     +--+
|  |<----|  |
|A |---->|B |
+--+     +--+
  |^ \^
  ||  \\
  ||   \\
  ||    \\
  V|     V\
+--+     +--+
|  |     |  |
|C |     |D |
+--+     +--+

Only the mixer node retransmits others' streams.  All nodes transmit
their own stream (except the mixer node).  All nodes receive the same
mixed stream.

This requires only one node to have N-1 links to other nodes,
(N-1 bidirectional links in the system).

This increases the amount of traffic into and out of that node
(assuming unicast traffic).

This is not a completely new idea.

There's a clear tradeoff here, and I'd guess that the primary thing
which favours the adoption of the single mixer is that small
changes, and very few resources are required on the weak nodes.
Neither scheme is particularly good for a large conference.

It's a research topic though, to scale these conferences using
only peer to peer mechanisms.  I'd probably expect to see the
results in the P2P research group before they come here.

Of course, I won't say anything about how multicast could
affect either of these methods ;)

Greg