Subject: RE: [MMUSIC] Re: Using payload types not specified in answer in offer/answer

From: "Sanjoy Sen"<[email-masked]>
Date: Fri, 15 Feb 2002 11:22:16 -0600

Doesn't the new consensus mean that we're back to the original requirement
that the client (offerer) needs to load multiple DSP's and be prepared to
receive on any of them (at least until the second offer/answer is made)? Am
I missing something? We should have a mechanism to avoid this for lesser
clients that can only use one DSP resource at a time. What happened to the
a=pickone attribute?

Sanjoy

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Friday, February 15, 2002 9:03 AM
> To: Jonathan Rosenberg
> Cc: Bert Culpepper; 'Roman Shpount'; [email-masked]
> Subject: Re: [MMUSIC] Re: Using payload types not specified 
> in answer in
> offer/answer
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> 
> > Really, the offer/answer model has some attributes which are merely
> > declarative (like ptime), and others which are shared and negotiated
> > (directionality). Therefore, the argument that SDP is 
> always declarative
> > holds no ground, since I think (hope) we can agree that 
> there are most
> > definitely attributes which are shared and negotiated. So, 
> are, or are
> > not, codecs part of this? If the goal, in general, is for a 
> common codec
> > to be used in each direction, then I think the view has to 
> be that they
> > are shared. While we could just reduce the set later with 
> an additional
> > offer, as Flemming has pointed out, the value that the O/A exchange
> > brings to the table is the ability to not need to do that.
> 
> Actually, it doesn't. With the present O/A text, we already 
> have to support
> all codecs in the offer until we get the answer. Furthermore, 
> since the
> offerer has no control over the answer, it is quite possible 
> that the answer
> contains more than one of the offered codec, and hence we are 
> back where we
> started. The only way to get down to one codec is a new 
> offer/answer exchange.
> Thus, the above can at most be seen as a possible optimization between
> offerers and answerers that both agree to pick just one 
> codec. Since it
> doesn't really solve the problem then, we loose some 
> functionality in the
> process, and we depart with what at least a lot of people had 
> understood
> (based on your earlier e-mail), we should stick to 
> yesterday's consensus.
> 
> -- Flemming
> 
> 
> >
> >
> > Thanks,
> > Jonathan R.
> >
> > Bert Culpepper wrote:
> > >
> > > >
> > > > Also note, that you can achieve almost the same by 
> issuing an updated
> > > > offer/answer with the the single codec, if that's what you want.
> > >
> > > I shouldn't be in so much of a hurry to jump in...You're 
> right, with an
> > > extra message exchange I can satisfy both goals.  This 
> will work for me.
> > >
> > > Thanks,
> > > Bert
> >
> > --
> > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> > Chief Scientist                         First Floor
> > dynamicsoft                             East Hanover, NJ 07936
> > [email-masked]                 FAX: (973) 952-5050
> > http://www.jdrosen.net                  PH:  (973) 952-5000
> > http://www.dynamicsoft.com
> 
> --
> Flemming Andreasen
> Cisco Systems
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 15 Feb 2002 12:47:53 -0500

Sanjoy Sen wrote:

>
>
> Doesn't the new consensus mean that we're back to the original
> requirement that the client (offerer) needs to load multiple DSP's and
> be prepared to receive on any of them (at least until the second
> offer/answer is made)?

Actually, we never departed from that.

> Am I missing something? We should have a mechanism to avoid this for
> lesser clients that can only use one DSP resource at a time. What
> happened to the a=pickone attribute?

There is basically no way of doing this in a backwards compatible way.
You can come fairly close with the current text, additional offer/answer
exchanges and/or new attributes, but at the end of the day, we can't
change the way SDP works. The level of expressiveness you are looking
for is provided by SDPng.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Feb 2002 13:34:21 -0500

Flemming Andreasen wrote:

> for is provided by SDPng.

Or, with another O/A exchange to reduce to a single codec. The a=pickone
never went forward, that is not the issue here as Flemming indicates.

-Jonathan R.