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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Nov 2000 05:10:31 -0500

> -----Original Message-----
> From: Billy Biggs [mailto:[email-masked]]
> Sent: Monday, November 20, 2000 7:54 PM
> To: Henning G. Schulzrinne
> Cc: Jonathan Rosenberg; SIP List
> Subject: Re: [SIP] New I-D on multiparty conferencing models
> 
> 
> Henning G. Schulzrinne ([email-masked]):
> 
> > >   [...] 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?
> > 
> > Yes. Each m line is independent and additive.
> 
>   This means that I could be asked to commit a huge denial of service
> attack.  There are security implications here.

I don't see this as fundmentally different. I could specify a multicast
address that has gazillions of receives, and do far more damage than
enumerating a list of unicast addresses.  Or, I could send you lots of
INVITEs with different SDPs. You are always at liberty to implement policy
to reject a call when you want. The point here is that there are legitimate,
and indeed, useful cases where multiple m lines of the same type are
present. This is one. If you read draft-rosenberg-sip-app-components, you
will see other important uses that center around dtmf.

I believe the use of multiple m lines is well within the spirit of SDP.
Indeed, in the original model of a multicast, multimedia conference, this is
quite reasonable. Consider a session thats a shuttle launch. I have one
audio stream which is the launch itself, and a separate one which is the
audio commentary from the reporter. I also have a video stream of it.
Perfectly reasonable. 

Now, whether this is supported is a separate quesiton. Part of the
motivation of this draft, and the 3pcc draft, is to show that these
seemingly subtle things, if you do them, can open a wealth of services and
features. 3pcc requires, for example, uses to accept re-INVITEs with
modified connection addresses. SIP doesn't say anything specific about this.
Likely people don't do it. The draft helps show why you should. In fact, at
the last bakeoff, we had people who added support for it in order to enable
3pcc apps. 

>   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. 

Right now, I expect no one supports it. Down the road, I would expect that
many phones support it, and those that don't, reject the call with some
reasonable response. 

 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.
> > 
> > That's a separate and necessary step.
> 
>   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. 

Mixing, perhaps. I'll note that I know of at least one embedded phone that
does this, though. As for sending to multiple locations, thats trivial when
the codec is the same. In fact, the RTP library we wrote, you can specify
multiple unicast destinations when you set up the session, and it sends to
all of them for you.

> It also might simply be too difficult for others to code.

I think you are overreacting a bit to the complexity involved for sending
the same audio stream to multiple destinations.

Billy initially wrote:
> >    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.

No signaling means is needed. The point here is that if a UA is doing this
kind of mixing, and it receives a REFER, it has to propagate it for the
conference to continue to function. Its a processing requirement that goes
along with support for the model in general. Not all UAs that support REFER
would do this; only ones actively performing this mixing role in a
conference.

>   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.

Hmm. This is a good point. I could wave my hands here and say "well, B
should know better than to transfer a multiparty call to a non-bridge
entity". But, thats somewhat unsatisfying. There may be a need to signal
whether REFER propagation is needed. I need to think about it.

-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