Subject: RE: [Sip] Negotiating audio mixing capabilities

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 5 Dec 2001 15:19:49 -0500

> -----Original Message-----
> From: Mark Zeren [mailto:[email-masked]]
> Sent: Saturday, November 17, 2001 11:22 AM
> To: [email-masked]
> Subject: [Sip] Negotiating audio mixing capabilities
> 
> 
> 
> I have several questions regarding the negotiation of audio mixing
> capabilities.
> 
> The recent "draft-rosenberg-mmusic-sdp-offer-answer-00.txt," 
> states: "when
> receiving multiple streams of the same type, the streams MUST be mixed
> before playing them out."
> 
> If the answerer cannot mix multiple streams (for example because of a
> hardware limitation) how should it indicate this information 
> to the offerer?

Presumably it would refuse all of the streams but one. If you want to
indicate that these streams don't need to be mixed, and that playing one at
a time is reasonable, I think the fid specification
(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fid-05.txt) would
allow you to declare that by defining each as its own group. However, this
is unclear from the fid specification, which really only covers how to send
to a group of streams, not the interpretation of receiving media from a
group of streams. That should probably be addressed.

> 
> If the offerer is optionally capable of mixing to one m line (e.g. by
> acquiring an external conferencing resource), how should that 
> capability be
> communicated to and allocated by the answerer?

There is no capability for that. These things can get really complicated.
You have to weight those complexities against those of doing mixing, which
is really not that complex for a small number of streams. The bigger problem
may be the lack of availability of access bandwidth (wireless handsets, for
example).

> 
> These questions also bear on the "Centralized Signaling, 
> Distributed Media"
> conferencing model recently described in
> "draft-ietf-sipping-conferencing-models-00.txt". In that 
> model a central
> controller would send an invite with multiple m lines, one 
> for each other
> participant in the call. How can a controller indicate that 
> it is also able
> to allocate a conferencing resource to mix the media for a 
> less capable
> terminal?

Same answer as above - there is no capability for that at this time.

Its not clear whether this is an SDP issue or a SIP issue; one approach
could be to add a warning header of sorts into a 4xx to indicate this (we do
that for other SDP related incompatibilities)

> Additionally, once the controller has allocated a 
> conferencing
> resource it may want to offer the resource to the other 
> participants in the
> call. A re-invite could be used to force all other parties to use the
> conferencing resource, but I see no way to offer the 
> conferencing resource
> as an "option" to the other participants.

I think this is an fid issue; you are offering a set of streams that are
grouped together, such that you want to choose one group or the other. I'd
welcome inputs from mmusic folks on whether something like this is in the
scope of fid.

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

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip