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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 4 Dec 2001 12:33:06 -0500

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: Colin Perkins <[email-masked]>
Date: Wed, 05 Dec 2001 01:36:02 -0500

--> Jonathan Rosenberg writes:
...
>   the start of a session description terminates the previous

This was one of the changes in sdp-new: SDP is now silent on the issue of
concatenation, since that seemed more appropriately specified as part of
the transport of SDP.

Are people happy with this change? I can revert it if not...

Colin

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 06 Dec 2001 05:23:59 -0500

>    the start of a session description terminates the previous

OK

> mean to be prepared to send after sending the offer?

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

> will do with media. What would be your proposal?

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.

> answerer {\MUSTNOT} generate media (or RTCP packets) for that

OK

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

Same again - I was trying to capture the bi-directional codec support on
bi-directional streams (see below).

> are supported. So, effectively, they are receive only.

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.

> on the new port. At that time, it {\MAY} cease listening for media on

OK

> synchronization between signaling exchanges of SDP and the media

Much better.

> prepared to receive using codecs from the new answer as soon as it is sent.

In practice, I don't think the one minute thing is a reasonable requirement, but
I will have to think more about alternative ways of synchronizing.

> This will appear in bis-06.

OK - thanks for the responses.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Dec 2001 11:26:05 -0500

> This will appear in bis-06.

I think this constraint is too strong. 

Consider:

	A                   B
        |   INVITE(sdp)     |  offers codecs X,Y
        |------------------>|
        |      OK(sdp)      |  accepts X, not Y,
        |<------------------|  would have accepted Z if offered
        |      ACK          |
        |------------------>|
        |   INVITE(no sdp)  |
        |------------------>|
        |      OK(sdp)      |  should be able to offer X,Z
        |<------------------|
        |      ACK (sdp)    |
        |------------------>|

In this standalone case, it probably isn't likely that A will be
interested in Z the second time if it wasn't the first time. But if A is
a B2BUA, it might be preparing to involve another party that is very
interested in Z. 

I believe the rule should be that on reinvites without sdp, the response
should be the same as last time, or a superset of that.

	Paul