Subject: [SIP] New I-D on multiparty conferencing models

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 19 Nov 2000 22:19:19 -0500

Folks,

I submitted a draft last Friday on multiparty conferencing models. It shows
how to do multiparty conferencing six different ways with baseline SIP.
Until it appears, you can pick up a copy at:

http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-conferencing-
models-00.txt

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Billy Biggs <[email-masked]>
Date: Mon, 20 Nov 2000 12:30:17 -0600

I would like to thank both Jonathan and Henning for providing this
important first step in allowing us to discuss conferencing in SIP.
This helps both to clarify and focus future work.

  That said, I have some problems with the draft.  I will start with the
most critical.

> 7 Centralized Signaling, Distributed Media
> 
>    In this conferencing model, there is a centralized controller, as
>    in the dial-in and dial-out cases. However, the centralized server
>    handles signaling only. The media is still sent directly between
>    participants, using either multicast or multi-unicast.
>    Multi-unicast is when a user sends multiple packets (one for each
>    recipient, addressed to that recipient). This is referred to as a
>    "Decentralized Multipoint Conference" in H.323. Interestingly, this
>    conference model is possible baseline SIP.
> 
>    It works through third party call control [13]. The conference
>    server uses re-INVITEs to each participant when a new one joins.
>    The re- INVITEs add a media stream that gets sent to the new
>    participant (and similarly in the reverse direction).

  I don't think this works.

  Let's look at some example SDP:

     ...
     c=24.22.33.44
     m=audio 6646 RTP/AVP 0
     c=33.24.44.22
     m=audio 7348 RTP/AVP 1

  Wouldn't this mean that if you use codec 0 then send to 24.22.33.44,
and if you use codec 1 then send to 33.24.44.22?  What document implies
that I send using both codecs to each address?

  If you really want to do this, you're going to need a stronger
description protocol.  SDP just isn't good enough.

  UAs should not be expected to support this method as you describe.

> 5 Ad-hoc Centralized Conferences
> 
>    [...]
> 
>    It is also possible to transition from a end system mixed
>    conference (even one with a complex connection topology), to a
>    centralized conference server. One user takes responsibility for
>    initiating the transition. It proceeds as described above. However,
>    the REFER request is sent to all SIP peers adjacent to the user. In
>    addition, when a SIP UA receives a REFER, they must not only act on
>    it as described above, but also generate a REFER to any of their
>    adjacent SIP peers. In essence, the REFER message is propagated
>    along the connection graph, starting at the root (which is the user
>    who initiates the transition). The transition will work so long as
>    the graph has no cycles (which is needed anyway, as discussed
>    above), and so long as only one user attempts to initiate the
>    transition. If multiple users attempt to initiate the transition at
>    the same time, the conference will break into two disjoint ad-hoc
>    conferences, with membership depending on the temporal dynamics of
>    the REFER propagation.

  This implies that REFER propagation should be automatic, but no method
is given to signal this.

  It doesn't seem reasonable to expect UAs to propagate a REFER along
their conferences.  For example, say A is in a 3-way call performing
End System Mixing:

                       A
                 D    / \
                     B   C

  And say that B REFERs A to D.  Should A propagate this REFER to C?
No.  There is no way to know if D is a conference bridge or simply
another phone.

  I think you should take this paragraph out.  It is confusing and
unnecessary in 99% of cases.  If the user of A knows that D is a
conference bridge, A can initiate a REFER to C if it wants to.  This
action should not be automatic.

> 2.5 Discovering Participant Identities
> 
>    The identities of other participants in the conference is NOT known
>    through SIP. Rather, it is learned through RTP. UAs with degrees
>    greater than one are RTP mixers. As such, they take the RTCP SDES
>    of the streams they mix, and aggregrate them into the RTCP stream
>    sent out. Since RTCP messages are sent infrequently, there may be a
>    delay between when a user joins, and when their presence is known
>    to the other participants.

  You might want to mention in the security section that announcing
participants via RTCP is not always desirable.  For example, if the user
wants someone to listen in on the call without announcing their presence
to the remote agent.

> 9 Whats Missing - Full Mesh
> 
>    [...]
>
>    As a baseline model, we believe that each INVITE, 200 OK response,
>    and ACK simply contain a header called Members. This header is a
>    list of URLs, and for each URL, there is a parameter that indicates
>    whether they are in the conference right now, and when they joined,
>    or whether they were previously in the conference, and when they
>    left. A UA simply performs a re-INVITE as it receives new
>    information. A periodic re-INVITE (ala session timer [15] will also
>    be needed to heal partitions and deal with other conditions that
>    may arise).

  I don't think it is clean to try and put all that information into the
SIP header.  In my opinion, what is needed is first a generall call
description language, which can describe the state of the conference as
a whole.  This is useful both for managing a full mesh call, or watching
the status of a call through a conference bridge.

  See some old notes on conference control at:

  http://www.billybiggs.com/sip-conf/17-jun-00-conf-architecture-draft-1.txt

  Most of the document is useless, but I do talk about the need for a
description language which is seperate from the control of the
conference.  I will attempt to update these notes based on your draft.

  One last note about your draft:

> 2 End System Mixing
>
>    [...]
> 
>    Note that this model has the serious drawback that the conference
>    ends when the mixing UA leaves the call.

  You can mention our Replaces draft. :)

  http://www.sip-happens.com/replaces/

--
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 20 Nov 2000 17:57:16 -0500

> that I send using both codecs to each address?

SDP does. SDP does *not* say that you choose the media line you like.
All media lines are sent simultaneously; unfortunately, this is implied
(set of media) rather than stated. In practice, I doubt that any
existing application will do this, but it has been done, e.g., for two
simultaneous languages. The lack of distinction between 'and' and 'or'
is a major flaw in SDP.

>   UAs should not be expected to support this method as you describe.

Indeed, I doubt that UAs will do this. They should support multiple
media lines with the same type, however, as this is useful beyond this
mixing model.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Billy Biggs <[email-masked]>
Date: Mon, 20 Nov 2000 17:56:08 -0600

Henning G. Schulzrinne ([email-masked]):

> >   Wouldn't this mean that if you use codec 0 then send to
> > 24.22.33.44, and if you use codec 1 then send to 33.24.44.22?
> > What document implies that I send using both codecs to each
> > address?
> 
> All media lines are sent simultaneously; unfortunately, this is
> implied (set of media) rather than stated. In practice, I doubt that
> any existing application will do this, but it has been done, e.g., for
> two simultaneous languages. The lack of distinction between 'and' and
> 'or' is a major flaw in SDP.

  Ok, so if I see:
         m=audio 6646 RTP/AVP 0 1 2 3

  Then I get to choose, but if I see:
         m=audio 6646 RTP/AVP 0
         m=audio 6656 RTP/AVP 1

  Then I don't get to choose?  I'm supposed to send to both?

> media lines with the same type, however, as this is useful beyond this

  Sorry, I don't follow.  If I see:
         c=22.22.22.22
         m=audio 6646 RTP/AVP 0
         c=33.33.33.33
         m=audio 6656 RTP/AVP 0

  Then it's asking me to send to both of them?

  I don't think that anyone will support this either.  I would say that
it is too late for SDP, and if you want to signal this, lets define a
stronger description protocol.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 20 Nov 2000 19:03:59 -0500

>   Then I don't get to choose?  I'm supposed to send to both?

Yes. Each m line is independent and additive.

>   Then it's asking me to send to both of them?

Yes. I believe that sdr actually allows this, but haven't tested this.

> stronger description protocol.

That's a separate and necessary step.

---

From: Billy Biggs <[email-masked]>
Date: Mon, 20 Nov 2000 18:53:41 -0600

Henning G. Schulzrinne ([email-masked]):

> >   [...] but if I see:

  This means that I could be asked to commit a huge denial of service
attack.  There are security implications here.

> Yes. I believe that sdr actually allows this, but haven't tested this.

  Again there are security implications.  My client should be free to
reject this SDP as if the caller didn't specify a supported codec.
IIRC, this might be a 406 response and a shutdown of the call.

  The assertion in the draft that "Interestingly, this conference model
is possible baseline SIP" is misleading.  It implies that all SIP phones
are expected to support it.  I guess detecting the situation and
shutting down the call is acceptable?

> >   I don't think that anyone will support this either.  I would say
> > that it is too late for SDP, and if you want to signal this, lets
> > define a stronger description protocol.
> 

  Well, then maybe the problem is that SDP is too powerful for use as a
base description protocol for SIP.  If supporting SDP means supporting:

  - Sending audio to multiple locations, and
  - Mixing audio from multiple sources

  ... then I think that will exceed the capacity of many embedded
phones.  It also might simply be too difficult for others to code.
Regardless, services which make use of these features must be aware that
they will not be able to interoperate with everybody.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 20 Nov 2000 20:00:57 -0500

Frankly, I don't see the difference in allowing media to be sent to one
address or two. There never was a guarantee that the media address is
the same as the signaling address (3pcc works based on that principle).
If you want denial of service, requesting a single video stream at high
rate is a far more effective mechanism than some piddling audio
streams... You don't need special SDP or end system capabilities for
that "feature".
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Billy Biggs <[email-masked]>
Date: Mon, 20 Nov 2000 19:14:06 -0600

Henning G. Schulzrinne ([email-masked]):

> Frankly, I don't see the difference in allowing media to be sent to
> one address or two. There never was a guarantee that the media address
> is the same as the signaling address (3pcc works based on that
> principle).  If you want denial of service, requesting a single video
> stream at high rate is a far more effective mechanism than some
> piddling audio streams... You don't need special SDP or end system
> capabilities for that "feature".

  True, but you do need video.

  Regardless, lets just talk about the assumptions we're making about
the capability of the clients.

  I don't expect all clients to be able to support:

  - sending audio to multiple locations, and
  - mixing audio from multiple sources.

  I don't think your draft should either.  Is that unreasonable?

---

From: Jay Batson <[email-masked]>
Date: Mon, 27 Nov 2000 21:54:25 -0500

>   I don't think your draft should either.  Is that unreasonable?

Protocols should not be designed with the "probability of implementation" 
in mind when the motivation for those probabilities is are based on 
"assumptions" about likely products to be built under market conditions of 
the moment.  Remember Moore's law -- the DSP and memory resources available 
to vendors (of client products) will change much faster than the protocol 
changes.

Protocols should be designed to specify behavior in ways that are 
technically logical, defensible, as-minimal-as-should-be, and yet provide 
flexibility and extensiblility so that they can have a long life, 
especially if these behaviors "advance the ball" (vs. replicate the 
status-quo).  There should also be an understood, graceful fallback / 
failure mechanism for what behavior happens if certain protocol features 
are not implemented in a participating system.

IMHO, the requirements placed on clients by the multiparty conferencing I-D 
meet these requirements.

If implementors belive that implementing a component of the protocol falls 
outside the functional and market constraints for a product being offered 
at a particular moment in time (given target market, price point, etc.), 
the implementor can choose to act according to the fallback / failure 
mechanism.  This behavior simply becomes a momentary component of 
differentiation between competing products.

But protocol designers should not make consideration of this choice a 
determining factor for inclusion in the protocol.

If "likelihood of implementation" were a factor in the specification of 
HTTP, MIME, RFC822, etc., we would have a much less interesting world now 
than we do.  Design for the future -- not the present, keeping Moore's (and 
Gilder's) laws in mind.  Designing for the lowest common denominator is boring.

Cheers
-jb

----------
Jay Batson
Pingtel Corp.
[email-masked]

781-938-5306 (office)
781-938-9650 (fax)