Subject: RE: [MMUSIC] Re: resolving open issues in offer/answer

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 3 Jan 2002 11:19:56 -0000

This is a null argument for not having the requirement.

As specified, it is a perfectly accepted normative requirement. As regards
conformance, it cannot be tested with a single point of control and
observation. Conformance could however be determined with an additional
point of control and observation between the application process and the SDP
process. Conformance testers don't like this, because it is rarely provided
as an accessible interface in implementations, but testing standards do
acknowledge the existence of such a testing model.

Lets concentrate on whether it is a reasonable requirement in the first
place.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Paul Kyzivat[SMTP:[email-masked]]
> Sent: 	21 December 2001 13:55
> To: 	Flemming Andreasen
> Cc: 	Jonathan Rosenberg; [email-masked]; [email-masked]
> Subject: 	Re: [MMUSIC] Re: resolving open issues in offer/answer
> 
> Sorry, but I still don't get it.
> 
> Let me put it another way. This is adding normative language requiring
> the sender of SDP to be prepared to send. How would that be verified? Is
> there any possible way to distinguish between being unprepared to send
> (nonconforming) and simply having no desire to send (conforming)?
> 
> 	Paul
> 
> Flemming Andreasen wrote:
> > 
> > Paul Kyzivat wrote:
> > 
> > > Comments below - Paul
> > >
> > > Jonathan Rosenberg wrote:
> > > >
> > > > Folks,
> > > >
> > > > I want to try and move swiftly towards closure of the open issues in
> > > > offer/answer. I presented slides at IETF 52 on these issues, which
> you
> > > > can pick up from:
> > >
> > > > ISSUE 2: Be prepared to send&recv on bidirectional stream when you
> send
> > > > the SDP. Consensus to update text to indicate that you need to be
> > > > prepared to both send and receive.
> > >
> > > I don't understand the point in requiring someone to be prepared to
> > > send.
> > >
> > 
> > There were two issues here. First one was that we always want codecs
> listed on
> > a bi-directional stream to indicate a send and receive capability.
> Second one
> > was, that even if you have only sent an initial offer, and not yet
> gotten a
> > response, it is possible to send media when using connection-oriented
> media
> > streams if the connection is established before you get the answer. In
> that
> > case, you need to be prepared to both send and receive at the time of
> the
> > offer.
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Jan 2002 09:18:26 -0500

OK. I will shut up. The requirement seems silly to me, but if others
want to believe it is meaningful then it does little harm to leave it.

	Paul