Subject: RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>

From: Orit Levin <[email-masked]>
Date: Tue, 4 Dec 2001 17:56:38 -0500

Hi Jonathan!
I agree with most of Flemming's comments.
There is an additional issue though. In order for the draft to become
clearer, it would be very helpful to provide  and use definitions
differentiating among the three cases:
1. a single media stream (i.e. a codec within an m-line)
2. (a proposal/offer/answer as) a single m-line (that may specify a number
of codecs)
3. (a proposal/offer/answer consisting of) several m-lines
Additionally, the meaning of "the source of the stream" is not clear enough.
Are you referring to one of the RTP/RTCP fields or is it based upon an
application interpretation? What correlation would it have to the three
cases above?
The Offer-Answer semantics may be different based on the three cases above.
For example, the controversial "mixing" part requires clearer definition:
 "When receiving multiple streams of the same type, the streams MUST be
mixed before playing them out."	
I guess, we are talking about multiple m-lines, otherwise the "mixing" would
have been implicit "in time". (The FID is yet a separately defined case.)
The provided example reads as it were the case of "de-multiplexing" rather
then mixing.
May be it is just a terminology problem here, but it seems that in the
majority of cases, the "mixing" is not required.
For example, if you are sending stereo, the last thing would be "to mix" it
by the receiving side.
If it is, indeed, the case of multiple m-lines, could you provide (a) more
visual scheme(s) for the use of the proposed "mixing"?

Thanks,
Orit Levin
Chief Architect
RADVISION Inc.
TEL: +1.201.529.4300 x 230
FAX: +1.201.529.3516

 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:[email-masked]] 
Sent:	Tuesday, December 04, 2001 12:33 PM
To:	'Flemming Andreasen'; Jonathan Rosenberg; Henning Schulzrinne
Cc:	MMUSIC
Subject:	RE: Comments on
<draft-rosenberg-mmusic-sdp-offer-answer-00.txt>

Flemming,

Thanks for the detailed comments. Responses inline.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 6:26 PM
> To: Jonathan Rosenberg; Henning Schulzrinne
> Cc: MMUSIC
> Subject: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
> 
> 
> Thanks for putting together
> <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>. A couple of 
> questions
> and comments:
> 
> - Section 2 specifies that "Either an e line or p line MUST 
> be present."
> however this was made optional in 
> <draft-ietf-mmusic-sdp-new-03.txt>. In
> general, I think we should avoid stating or repeating 
> requirements that
> belong in the SDP specification itself.

Yes, good points.

I don't want to make offer-answer dependent on sdp-new. However, what I will
do is state that the SDP must be valid, as specified in rfc2327, except that
the restriction on having either an e or p line is lifted, so that neither
may be present. This brings us into alignment without introducing a
dependency. The draft says that its recommended that you accept SDP without
these, but that wording is not strong enough for interop.

> 
> - Section 2 mentions that SDP allows for concatenation of multiple
> session descriptions. I can't seem to find this in the SDP 
> spec - where
> does it say that ?

Page 7:

   When SDP is conveyed by SAP, only one session description is allowed
   per packet.  When SDP is conveyed by other means, many SDP session
   descriptions may be concatenated together (the `v=' line indicating
   the start of a session description terminates the previous
   description). 

> 
> - Section 2 says that "Once the offerer has sent the offer, it MUST be
> prepared to receive media described by that offer." For send/receive
> media streams, I believe the offerer must also be prepared to 
> send such
> media (although obviously it can't until it gets the answer).

I don't understand. If it can't send until it gets the answer, what does it
mean to be prepared to send after sending the offer?

> 
> - Section 2.1: I share the concerns raised by others about 
> the following
> sentence: "When receiving multiple streams of the same type, 
> the streams
> MUST be mixed before playing them out". This seems overly restrictive.

Without well defined behavior, I don't see how we will have reasonable
interoperability. Applications will depend on knowing what the end system
will do with media. What would be your proposal?

> 
> - Section 3: The sentence "The definition of rejected is both neither
> offerer and answerer MUST NOT generate media (or RTCP 
> packets) for that
> stream." doesn't seem to parse quite right.

OK. How about:

If a stream is rejected, the offerer and
answerer {\MUSTNOT} generate media (or RTCP packets) for that
stream. 

> 
> - Section 3 says that "Once the answer has been sent, the 
> answerer MUST
> be prepared to receive media as described in the answer.". For
> send/receive streams I believe the answerer must also be prepared to
> send such media.

Same as above; I don't understand what this means.

> 
> - Section 3.1. says (for sendrecv media streams) that "The stream MAY
> indicate additional codecs, not listed in the corresponding stream in
> the offer, that the answerer is willing to receive with." 
> This makes the
> interpretation of the codecs listed context-dependent which is fairly
> unfortunate. If the answerer wishes to add additional codecs to the
> sendrecv stream, he should be able to both send and receive 
> those codecs
> (regardless of whether the offerer seems interested in receiving media
> encoded with such codecs).

Well, he can't send with them, since the offerer hasn't indicated that they
are supported. So, effectively, they are receive only.

> 
> - Section 4.3 says that "The offerer MUST NOT cease listening 
> for media
> on the old port until media arrives on the new port. At that time, it
> MAY cease listening for media on the old port.". This means that you
> allow the presence of media to serve as confirmation of your offer. I
> think this opens up a race condition and would prefer getting 
> the answer
> back as well.

Thats a good point. Text now reads:

soon as the offer is sent. The offerer {\MUSTNOT} cease listening for
media on the old port until the answer is received and media arrives
on the new port. At that time, it {\MAY} cease listening for media on
the old port. 

> 
> - Section 4.3. says that "When a new codec is used with a dynamic
> payload type number, it MUST NOT reuse a dynamic payload type number
> used previously in the session.". I don't think the sentence 
> accurately
> captures the intention (since "new codec" seems to simply refer to the
> most recent offer) which I belive is simply to forbid changing the
> mapping from a given payload type to a given codec. If that 
> mapping was
> done X offer/invite exchanges ago, and we want to reuse it now, it
> should be allowed.

Correct. 

I've reworded. It now reads:

The list of codecs used in the session {\MAY} be changed. To do this,
the offerer creates a new media description, with the list of media
formats in the m line different from the corresponding stream in the
previous SDP. This list {\MAY} include new codecs, and {\MAY} remove
codecs present from the previous SDP. However, the mappings of a
particular codec to a dynamic payload type number {\MUSTNOT} change
for the duration of a session. For example, if A generates an offer
with G.711 assigned to dynamic payload type number 46, and then later
updates the session by removing the codec, and then once again adds it
back, dynamic payload type number 46 could not be used for any other
codec except for G.711. However, it is acceptable for multiple payload
type numbers to be mapped to the same codec, so that an updated offer
would use payload type number 72 for G.711. The mappings need to
remain fixed for the duration of the session because of the loose
synchronization between signaling exchanges of SDP and the media
stream. 

Is this better?

> 
> - Section 4.3 is silent on what the offerer and answerer do with the
> codecs (and media types) from the previous successful offer/answer. At
> what point do the offerer and answerer stop accepting media 
> according to
> the old offer and answer ?

Good question. Its simple when there is no overlap in the set of codecs
between the original offer and the new one; you accept on the old until you
get both the answer AND someone starts using the new codecs. When there is
overlap, its more complex. If the other side changes codecs to one of the
overlapping codecs, you don't know if this was due to receiving the offer,
or just an unrelated change in selection of media for the previous offer.

How about this:

The corresponding media stream in the answer is formulated as
described in Section \ref{sec:sdp:answer}. The offerer MUST be
prepared to use codecs from the old offer/answer exchange, until it
(1) receives the answer, and (2) receives media using a codec not
previously allowed from the old offer/answer exchange, or one minute
elapses, which ever happens first. The offerer MUST send using codecs
from the new offer/answer as soon as the answer is received, and MUST
be prepared to receive using codecs from the new offer as soon as the
offer is sent. The answerer MUST be prepared to use codecs from the
old offer/answer exchange until it receives media using a codec not
previously allowed from the old offer/answer exchange, or one minute
elapses, which ever happens first. The answerer MUST send using codecs
from the new offer/answer as soon as it sends the answer, and MUST be
prepared to receive using codecs from the new answer as soon as it is sent.

> Also, what happens if the offer is 
> rejected ?

You no longer need to listen for media using the new codecs/ports. I added a
few sentences to that effect:

Of course, if the offered stream is rejected, the offer can cease
being prepared to receive using the new port as soon as the
rejection is received.

and:

Of course, if the offered stream is rejected, the offer can cease
being prepared to receive using any new codecs as soon as the
rejection is received.

> 
> - Finally, for generality, the I-D should probably avoid some 
> of the SIP
> specific wording (e.g. "re-INVITE", "sending a SIP message") 
> and simply
> talk about sending offers and answers.
> 

Done.

This did require the movement of one paragraph from this draft back into
bis:

This means that a 
re-{\INVITE} {\MAY} contain no SDP, so that the 200 OK to the
re-{\INVITE} contains the offer. In this case, the
offerer {\MUST} offer the same SDP it provided previously. This is to
ensure that the offered SDP in the 2xx will be acceptable to the UAC,
as there is no way to reject it.

This will appear in bis-06.

Thanks,
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

---

From: [email-masked]
Date: Wed, 5 Dec 2001 14:58:43 +0100

Hi,

*******************

you write "The list of payload types for each media stream conveys two 
pieces of
   information, namely the set of codecs that the offerer is capable of
   sending and/or receiving..."

my concern is that this description of the "codec" is *only* the mime 
type,

however for several recent RTP payload formats 
the mime type is "too vague" an indication:
AMR, MPEG-4 video, MPEG-4 AAC, MPEG-4 CELP ...
they all have to be described with more that the payload type.
Typically at the minimum a  mime parameter
(in MPEG-4 the profile-level-id) is required for a
fruitful negociation... because the mime type encompasses
a sometimes quite large number of very different configurations ...

I think it is possible to allow for any number of
mime parameters to be added using a a=fmtp line:
as in the following (modified) example

 v=0
   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
   s=New board design
   e=[email-masked]
   t=0 0
   c=IN IP4 host.anywhere.com
   m=audio 49170 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 51372 RTP/AVP 31
   a=rtpmap:31 H261/90000
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000
   m=video 55000 RTP/AVP 33
   a=fmtp:33  profile-level-id=1
   a=rtpmap:33 MPEG4-GENERIC/90000

what do you think ?

*************************

In a similar fashion what about the bandwidth indication ?
(same stream, different bit rate)

   m=video 55000 RTP/AVP 33
   a=fmtp:33  profile-level-id=1
   b=AS:64
   a=rtpmap:33 MPEG4-GENERIC/90000
   m=video 55000 RTP/AVP 34
   a=fmtp:34  profile-level-id=1
   b=AS:32
   a=rtpmap:34 MPEG4-GENERIC/90000

*************************

you do not mention RTSP explicitely in the text.

I would like to understand if this draft could support such a thing i.e. a 
scenario
where a video on demand server, upon a RTSP describe
sends back an "offer" listing a number of choices for a given movie
that the client will pick from for example using a SET_PARAMETER
with Accept: application/sdp as in:

     C->S: DESCRIBE rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 1

     M->C: RTSP/1.0 200 OK
           CSeq: 1
           Content-Type: application/sdp
           Content-Length: 164

           << put the SDP offer here >>

     C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 2
           Content-type: application/sdp
           Content-length: 28

           sdp-answer: << put the SDP answer here>>

     S->C: RTSP/1.0 OK 200 OK
           CSeq: 2

Could we also define the "sdp-answer" key word in your draft ?

*****************************

I understand that the limit to the number of different configurations
that can be thus "offered" is the number of dynamic payload types,
which is not a lot. 

Is that correct ?

Regards,

Philippe Gentric
Software architect
Philips Digital Networks - MP4Net
51 rue Carnot B.P. 301
92156 Suresnes FRANCE
tel: +33(0)147283740
fax: +33(0)147283725
[email-masked]
http://www.mpeg-4.philips.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Dec 2001 16:36:21 -0500

> From: Orit Levin [mailto:[email-masked]]
> Sent: Tuesday, December 04, 2001 5:57 PM
> To: 'Jonathan Rosenberg'; 'Flemming Andreasen'; Henning Schulzrinne
> Cc: MMUSIC
> Subject: RE: Comments on

My definition of "stream" is the m-line.

> application interpretation? What correlation would it have to 

Each stream (read: m-line) needs data to provide input to codecs for
eventual RTP transmission. In a PSTN gateway, there is only one "source",
which is the incoming circuit. For a multimedia conferencing system, we
might have several sources of audio, for example - a mike in room one, a
mike in room 2, and a vcr playing pre-recorded content. 

> The Offer-Answer semantics may be different based on the 

Not sure what you mean.

> I guess, we are talking about multiple m-lines,

yes.

> otherwise the 
> "mixing" would

True enough. As I pointed out in another thread, what this is really trying
to say is that the streams should all be presented to the user
simultaneously, however that needs to be done. If there is only one "sink"
available - like the PC speaker, you'll need to mix. If there are multiple
"sinks" - then I would generalize to say that the mapping of received media
to sinks is also policy dependent, so long as each stream maps to some sink.

> visual scheme(s) for the use of the proposed "mixing"?

I don't know what you mean by "a more visual scheme".

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Dec 2001 16:52:34 -0500

> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2001 8:59 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Comments on

No; if there are fmtp and rtpmap attributes, the payload type number
indicates the codec type and the associated parameters associated with that.

>    a=rtpmap:33 MPEG4-GENERIC/90000

Your example agrees with my statement above. I think perhaps clearer wording
is needed in the document to indicate that the number indicates codec and
parameters.

I changed the text to:

  The list of payload types for each media stream conveys two pieces of
  information, namely the set of formats (codecs and any parameters
  associated with the codec, in the case of RTP)
  that the offerer is capable of sending and/or receiving (depending on
  the direction attributes), and, in the case of RTP, the RTP payload
  type numbers used to identify those formats. If multiple formats are

I think that would include your case above. Note that you would need FID in
order to use this SDP above, since they are alternatives.

> you do not mention RTSP explicitely in the text.

Right. It used to mention SIP, but I have removed SIP references. It now
stands as a signaling independent (ie, SIP, RTSP, etc.) mechanism for
offer/answer exchanges with SDP.
I don't think it should mention either SIP or RTSP.

>            sdp-answer: << put the SDP answer here>>

I don't know SDP all that well, but it seems fine to me. I think it would be
great if its direclty usable by RTSP; arguably that should be a goal.

> Could we also define the "sdp-answer" key word in your draft ?

I don't know what you mean by "sdp-answer" keyword. Is that an RTSP thing?

I believe so. Is that really limiting?

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Dec 2001 21:32:03 -0500

inline.

> Sent: Thursday, December 06, 2001 5:24 AM
> To: Jonathan Rosenberg
> Cc: Henning Schulzrinne; MMUSIC
> Subject: Re: Comments on
> It basically means that on bi-directional streams, I always 
> support the codec
> bi-directionally, since we cannot specify asymmetric codec usage on a
> bi-directional stream in SDP (this may be clearer if you 
> continue reading
> below).

OK, still confused... I understand that the codec is bidirectional, but the
offerer doesn't need to send with it until the answer arrives, but it does
need to be able to receive with it once the offer is sent. It may very well
be that for real implementations, its "ready" to do both anyway, but it
won't send until the answer arrives.

> Ideally, I would have a default (which could be the above) 
> and then attributes
> enabling me to specify different behavior. However, since 
> such attributes would
> have to be defined as extensions, it raises the usual 
> question of how to deal
> with extensions and ensure interoperability (which btw 
> reminds me that we should
> give some consideration to including the PINT "require" 
> attribute in sdp-new,
> and personally I wouldn't mind seeing a "supported" attribute 
> too). Also, while
> mixing for audio seems like a reasonable default, I don't 
> know what it means to
> mix for example a video stream, so maybe we should only 
> specify mixing as the
> default for audio streams.
> 
> However, this particular issue probably deserves some more discussion.

Indeed. I will be talking about this during the discussion in mmusic at IETF
on Monday. That said, I think my new definition, which is that you are
required to present all received media to the user, is more general and
would handle the video case.

> I disagree that they aren't supported. All you know is that 
> the offerer has not
> indicated a desire to send or receive with this codec. You 
> are inferring a
> uni-directional capability by this being an answer as opposed 
> to an offer, and
> that's what I'm not happy about since it deviates from the 
> normal case of
> bi-directionality by context only. This seems to make things 
> like third party
> call control more complicated and potentially lead to 
> unnecessary failures. I
> can see other restrictions as well.

Hmm. The 3pcc case is a good one, thanks for pointing that out.

I was trying to work in a reasonable way to handle unidirectional dtmf from
a end system to a media server of sorts. This is an important case. Some
other ways to handle it, perhaps:

a. answerer can add codecs to the m line, but they would need to be sendrecv
if the stream is sendrecv. This means a media server would need to be able
to both send and receive.

b. If the media server wants dtmf, we could have it reinvite the client,
adding another m line with the dtmf, and using FID to group it with the
original media stream. This has the disadvantage of requiring FID support
and extra messaging.

c. Even though the UA doesn't support receiving of DTMF, it declares it as
an allowed sendrecv codec in its offer. Just better hope no one sends with
it...

None of these seem particularly appealing. I welcome other suggestions. I'm
not trying to solve the more general problem of unidirectional codecs in a
bidirectional stream, since in general I don't think its a real problem, but
the DTMF case is a real problem.

> In practice, I don't think the one minute thing is a 
> reasonable requirement, 

Too long, too short, or you don't want timer based?

Another way to synchronize is to start including RTP sequence numbers in the
SDP's, although that would only work for the answerer. In other words, the
answer's SDP says, "this SDP is the one which applies to all RTP packets
after SN XXXXX". It can do that since the answerer knows enough information
about what codecs to use upon transmission of its SDP; not so for the
offerer. It would require a three-way handshake for that.

> 
> OK - thanks for the responses.

Thanks for your detailed comments.

-Jonathan R.

---

---

From: [email-masked]
Date: Mon, 10 Dec 2001 04:31:58 +0100

0.

RTSP point taken, should be transport agnostic,
pratical exemples would be nice though

1.

"sdp-answer" in *not* in the RTSP spec,
just a figment of my imagination, so far,
and that was my point: I think it would be needed,
but then what document should define it ?
(oh no ! not another draft ?)

2.

having the number of dynamic payload type as a limit
seems to me as bad, I can imagine cases where the server
would like to propose a *lot* of alternatives,
for example the bit rate is a typical parameter that can have a lot of values

See you in SLC

Philippe Gentric
Software architect

Jonathan Rosenberg <[email-masked]>@ISI.EDU on 12/07/2001 10:52:34 PM

Sent by:  [email-masked]

To:     Philippe Gentric/LIM/CE/PHILIPS@EMEA1
        Jonathan Rosenberg <[email-masked]>
cc:     [email-masked]
        [email-masked]
Subject:  RE: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>

I changed the text to:

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 9 Dec 2001 23:56:12 -0500

> Sent: Sunday, December 09, 2001 8:32 PM

Other folks seemed to want no mention of SIP at all; so either there should
be examples of neither or examples of both.

> (oh no ! not another draft ?)

I don't understand what you are proposing exactly. What is it needed for?

> for example the bit rate is a typical parameter that can have 
> a lot of 
> values 

Yeah, but not more than 127, I would guess. We've not seen this problem in
reality yet, not even close...

-Jonathan R.

---

> indicates the codec type and the associated parameters 
> associated with 
> that.
> 
> 
> > 
> I think that would include your case above. Note that you 
> would need FID 
> in
> I don't know SDP all that well, but it seems fine to me. I 
> think it would 
> be