Subject: [MMUSIC] WG Last Call for Offer/Answer

From: Joerg Ott <[email-masked]>
Date: Sat, 02 Feb 2002 17:59:46 +0100

Folks,

this is to announce Working Group Last Call on

        draft-ietf-mmusic-sdp-offer-answer-00.txt

for Proposed Standard.  Please note that this document is a
revision of draft-rosenberg-mmusic-offer-answer-00.txt.

The WG Last Call is to expire in two weeks, on 16 Feb 2002.

Please note that this document is referenced by SIP bis06
and thus is crucial to the 3G work.  So, please, review this
document quickly (it is not that long) and should you 
have any comments, please submit them asap to the MMUSIC
mailing list and the authors.

Thanks a lot,
Joerg
co-chair, MMUSIC

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

---

From: "Peili Xu" <[email-masked]>
Date: Mon, 4 Feb 2002 09:52:14 +0800

In section 4 "Protocol Operatioin":

It says that the agent Must Not generate a new offer if it has received an offer which it has not yet answered or rejected.

But for early media we use 180/PRACK to offer and answer the early media just before

the Invite/200 interaction is completed.

Is this method break the Offer/Answer law?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 03 Feb 2002 21:34:34 -0500

Peili Xu wrote:
> It says that the agent Must Not generate a new offer if it has received
> an offer which it has not yet answered or rejected.
> 

No. It works like this:

INVITE (offer 1) -->
<-----183 (answer 1)-

<------200 OK (offer 2)--
-------ACK (answer 2)---->

that is, the 200 OK is a new offer, and then SDP is present in the ACK
with an answer. 

This is different from the "common" practice today for early media,
which has the 183 as an anwer, with a 200 OK that repeats the same SDP.
I believe there will largely be backwards compatibility. If the UAS does
the "common" thing when talking to an element compliant to bis/o-a, it
will send SDP in the ACK, but so long as its not different from the
offer in the INVITE, there won't be any issues. 

-Jonathan R.

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 11 Feb 2002 20:19:52 -0500

Some comments below:

- p.2 says "The offer/answer model defined here is the mandatory
baseline mechanism used by the Session
Initiation Protocol (SIP) [3]". This requirement seems to belong in SIP,
not offer/answer.

- p. 3:    Definition of Answerer says "An agent capable of sending
and/or receiving media...". The ability to
send/receive media should not be included here, i.e. strike "capable of
sending and/or receiving media,"

- p. 3:    Definition of Offerer: strike "capable of sending and/or
receiving media,"

- p. 4:    "The agent receiving the offer MAY generate an answer, or it
MAY reject the offer.". At least in the unicast case, MUST you not
always generate an answer which may either accept or reject the offer ?

- p. 4:    "However, it MUST NOT generate a new offer if it has received
an offer which it has not yet answered or reject.". I'm not sure what
this buys you since each side may generate an offer simultanously and
hence you have to deal with the race anyway. (nits: "reject =>
rejected", and offers are either accepted or rejected, but always
answered)

p.4:    "The offer MAY contain zero or more media streams..." A fairly
empty statement (how do you not satisfy this ?).

Section 5.1, first paragraph:    You may want to elaborate on sendonly,
recvonly, etc as a session attribute versus as a media attribute for
specific media streams.

p. 6:    "However, for sendonly and sendrecv streams, the answer might
indicate different payload type numbers for the same codecs, in which
case, the offerer MUST send with the payload type numbers from the
answer." Should add a sentence that the answerer MUST still send using
the payload types from the offer.

p. 8, last paragraph:    Only recvonly and sendrecv streams are
discussed. For completeness, sendonly streams should be mentioned as
well. Also, consider moving this paragraph to right after the first
paragraph on p.6, where similar issues are discussed.

Section 5.2, first paragraph:    I'd suggest writing this from the
perspective of the offerer (like the rest of section 5), i.e. "answerer
can only send (receive)" => "offerer can only receive (send)".

p.9:    Should state explicitly whether sendonly and sendrecv streams in
an answer are allowed to contain any additional media formats or not.

p. 10:    "In that case, the answer MAY contain fmtp parameters, and
those MAY have the same values as those in the offer, or they MAY be
different." I agree with this and understand the difficulty in saying
something more specific, however it still leaves open the question of
how to negotiate fmtp parameters between an offer and an answer. Should
there be a sentence saying that people defining fmtp parameters should
define how they are negotiated in offer/answer ?

p. 10:    "The answerer MAY include a ptime" => "The answerer MAY
include a non-zero ptime"

p. 10:    "When sending media, it SHOULD use a packetization interval
equal to the value of the ptime attribute in the offer, if any was
present.". Since ptime is a media stream attribute, this can be
difficult to do if multiple media formats are specified. There should be
a rounding rule to account for that (e.g. use closest non-zero ptime if
you can't use the ptime specified).

p. 11:    "Similarly, the directionality information in the answer
(sendonly, recvonly, or sendrecv) MUST equal that of the offer." It may
be worth spelling it out more clearly what this means, since it differs
from the unicast.

p. 13:    "Otherwise, the media description for the removed stream
SHOULD be formatted identically to the corresponding stream in the
previous SDP."    Add ", except for the list of media formats."

p. 13:    "Removal of a media stream implies that media is no longer
sent for that stream.". Add sentence "Furthermore, when RTP was used for
the media stream, RTCP reports will no longer be sent or received."

Section 8.3.1, first paragraph:    "The offerer MUST NOT cease listening
for media ..". In practice, it will not always be possible to satisfy
this requirement, and hence it should rather be "SHOULD NOT". (Nit:
"listening for" should be "receiving" - twice in the paragraph).

Section 8.3.1, second paragraph:    "The answerer MUST NOT cease
listening for media on the old port until media arrives on the new
port.". Same comments (also "listening for" => "receiving").

Section 8.3.2, first paragraph:    "the mapping from a particular
dynamic payload type number to a particular codec MUST NOT change".
Needs to be clarified that it applies on a per media stream basis and
not across the entire session.

Section 8.4:    Section seems to be unicast specific. Both heading and
section text should reflect this.

Section 9:    Since the "capabilities" SDP is indistinguishable from an
"offer/answer" SDP, we should make it clear, that this is determined by
the context within which the SDP is provided (for example a SIP OPTIONS
as opposed to INVITE).

Section 9:    "The transport component of the "m=" line indicates the
preferred transport for that media type.". Not sure this is ideal. For
example, if I support both RTP and SRTP, do I only indicate one of them
(similar issue with  T.38 UDP or TCP) ?

Also, I have some strictly editorial nits which I'll send off-line.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Feb 2002 01:07:17 -0500

Flemming,

Thanks for your comments. Responses inline.

> Initiation Protocol (SIP) [3]". This requirement seems to belong in SIP,

Its not a normative statement; it merely provides a context for the
reader of this document. I think its valuable to note that this
mechanism is what SIP uses.

> sending and/or receiving media,"

I got a similar comment in private email. I removed the text.

> - p. 3:    Definition of Offerer: strike "capable of sending and/or

Done.

> always generate an answer which may either accept or reject the offer ?

No. You can reject the offer outright. In the case of SIP, that would
mean sending
a 488. There is no answer in the 488.

> rejected", and offers are either accepted or rejected, but always

The nit has been fixed already. 

I have also already added text saying that the higher layer protocol
needs to provide a away to resolve the glare condition of both sending
offers simultaneously. It is always best to prevent those kinds of glare
conditions from happening, since they do take time to resolve (can be
seconds, at least, for the sip glare resolution mechanisms). Thus, the
text about not sending an offer when you have one outstanding is a good
one, I think. 

> empty statement (how do you not satisfy this ?).

Good point. The sentence is needed to preface the following sentence,
which define a meaning for zero media streams. So, I've reworded the
first sentence to be non-normative. The first two sentences now read:

The offer will contain zero or more media streams (each media stream
is described by an m line and its associated attributes). Zero media
streams implies that the offerer wishes to communicate, but that the
streams for the session will be added at a later time through a
modified offer. 

> recvonly, etc as a session attribute versus as a media attribute for

Excellent point. The paragraph now reads:

If the offerer wishes to only send media on a stream to its peer, it
{\MUST} mark the stream as sendonly with the a=sendonly attribute. We
refer to a stream as being marked with a certain direction if a
direction attribute was present as either a media stream attribute or
a session attribute. If the offerer wishes to only receive media from
its peer, it {\MUST} mark the stream as recvonly. 
<snip>

> the payload types from the offer.

Yes, thats a good point. That belongs farther down, in the section on
answerer behavior. The bottom of that paragraph now reads:

<snip>
It {\SHOULD} send media using a banwdith no
higher than the value of the bandwidth attribute in the offer, if any
was
present. The answerer {\SHOULD} send using the most preferred codec in
the offer supported by the answerer. In the case of RTP, it {\MUST}
use the payload type numbers from the offer, even if they differ from
those in the answer.

> paragraph on p.6, where similar issues are discussed.

Actually its page 7. I added a sentence on sendonly. 

I like the paragraph where it is, since it descsribes the processing
that the offerer follows after sending the offer, but before the answer.
The first paragraph on p. 6 describes the general meaning of the
direction attributes and m lines.

> can only send (receive)" => "offerer can only receive (send)".

Actually, I've been trying to get my arms around exactly what the
meaning is for multicast. The text thats there now, or your text, are
both wrong I think; they take a unicast view of the SDP. Really, for
multicast, it should be like the SAP usage. If a stream is recvonly,
then all participants, including the offerer and answerer, will only
receive on it. This is already reflected in how the answer is generated
(the directionalities are not flipped). So, I have reworded this section
to read:

If a session description contains a multicast media stream which is
listed as receive (send) only, it means that the participants,
including the offerer and answerer, can only receive (send) on that
stream. This differs from the unicast view, where the directionality
refers to the flow of media between offerer and answerer.

> an answer are allowed to contain any additional media formats or not.

We're discussing that one on the list... I've logged it in bugzilla as
an open issue.

> define how they are negotiated in offer/answer ?

I was debating that. I didn't put it in because I thought it was too
burdensome for drafts that define them, but its probably a good idea.
I'll add it. Speak now if you have a problem with that.... Here is the
sentence I tacked on here:

SDP extensions
that define new parameters {\SHOULD} specify the proper interpretation
in offer/answer. 

we can debate whether this is SHOULD or should; a similar debate is
going on in bis about whether such statements even belong in bis.
However, I think normative makes sense, and unlike bis, where we have
another document which defines rules for extensions
(draft-ietf-sip-guidelines), there isn't anywhere else to put it.

> include a non-zero ptime"

I didn't include that restriction for the offer, and you had no comment
on it there. Do I interpret this to mean you want this restriction only
for the answer, or do you really want it for both? It had never even
occurred to me to use a zero ptime, I don't even know what that would
mean....

> you can't use the ptime specified).

This is really a general SDP issue, not specific to O/A. Do we want to
discuss it here? Probably sdp-new should clarify this.

> be worth spelling it out more clearly what this means, since it differs

I mention it in the text on constructing the offer, see above response.

> previous SDP."    Add ", except for the list of media formats."

I rewrote this altogether, since the stream really isn't formatted at
all identically to the corresponding stream in the previous SDP. It now
reads:

A stream that is offered with a port of zero {\MUST} be marked with
port zero in the answer. Like the offer, the answer {\MAY} omit all
attributes present previously, and {\MAY} list just a single media
format from amongst those in the offer. 

> the media stream, RTCP reports will no longer be sent or received."

Added:

In the case of RTP, RTCP transmission also ceases.

> "listening for" should be "receiving" - twice in the paragraph).

On MUST NOT -> SHOULD NOT; OK, I made that change. I also added a note
that said if you don't, there could be media loss during the transition.
I don;'t want to encourage people to break the SHOULD. 

Regarding listening for -> receiving, I disagree. Listening is not the
same as receiving; you can be listening, but receive nothing. Listening
is the ability to receive. In this case, it truly is the ability to
receive, not the actual act of receiving which is mandated.

> port.". Same comments (also "listening for" => "receiving").

Same as above.

> not across the entire session.

OK. I clarified.

> section text should reflect this.

I changed the section heading to "putting a unicast stream on hold". I
see no need to repeat that within the body text.

> the context within which the SDP is provided (for example a SIP OPTIONS

Good point. Added:

Since SDP has no way to indicate that the message is for
the purpose of capability indication, this is determined from the
context of the higher layer protocol.

> (similar issue with  T.38 UDP or TCP) ?

Yes. Its not really preferred, its "the one". If you want to indicate
support for both SRTP and RTP, you would pick one in the offer, include
simcaps indicating the other. Similar in the answer. THe offerer could
then send an updated offer switching to SRTP. This is discussed in the
unify draft.

> Also, I have some strictly editorial nits which I'll send off-line.

OK, thanks. I appreciate your comments.

-Jonathan R.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Feb 2002 09:20:53 -0500

Hi Jonathan.

Thanks for the responses - I've snipped the ones we are in sync on and/or are
being discussed elsewhere. Whatever is left here is really minor.

> a 488. There is no answer in the 488.

OK, however an answer may also reject an offer by rejecting the streams. No
big deal.

> for the answer, or do you really want it for both?

Should apply to both.

> It had never even

Me neither, but then again I don't think it makes any sense to have bandwidth
attributes with a value of zero, but I'll leave that one alone ;-)

> discuss it here? Probably sdp-new should clarify this.

Good point (only minor issue then is that we are referencing RFC 2327
throughout, and not sdp-new).

> I mention it in the text on constructing the offer, see above response.

I still think it's worth spelling it out, since the less than careful reader
may not pick up on it. Not a big deal.

> In the case of RTP, RTCP transmission also ceases.

Not only that, you also will not accept any incoming RTCP messages, right
(transmission only implies sending) ?

> see no need to repeat that within the body text.

I like being explict but OK. How about at least adding "unicast" in the first
paragraph, i.e. "one or more media streams" => "one or more unicast media
streams".

> then send an updated offer switching to SRTP. This is discussed in the

Never mind - I got confused on OPTIONS for a second.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Feb 2002 11:03:51 -0500

> OK, however an answer may also reject an offer by rejecting the streams.

Right, of course. However, there is still in answer in that case. So,
the two cases still remain - MAY generate an answer, or MAY reject it.

> > for the answer, or do you really want it for both?

I'll add nonzero, but I suspect most folks wouldn't have even thought to
put zero in there.

> throughout, and not sdp-new).

I'd rather not discuss this in O/A, even if we only refer to 2327. In
reality, people can and will look at sdp-new. What we do need to do is
make sure that the text on this goes into sdp-new...

> may not pick up on it. Not a big deal.

OK. I added this:

This is because all
participants in a multicast session need to have equivalent views of
the parameters of the session, and underlying assumption of the
multicast bias of RFC 2327.

> (transmission only implies sending) ?

True, and then I need to say the same for the RTP itself, since the text
also only says to stop sending. I'll change. It now reads:

Removal of a media stream implies that media is no longer sent for
that stream, and any media that is received is discarded. In the case
of RTP, RTCP transmission also ceases, as does processing of any
received RTCP packets.

Done.

Thanks,
Jonathan R.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Feb 2002 11:10:26 -0500

Looks good.

Thanks a lot

            Flemming

--
Flemming Andreasen
Cisco Systems

---

From: "Peili Xu" <[email-masked]>
Date: Tue, 19 Feb 2002 10:48:41 +0800

But in bis07 line 2036 it reads:
"Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent 
offers in any responses to the INVITE. Since only the UAC can send PRACK, this means the a UAS 
based on this specification alone can never generate subsequent offers. "

This means that the UAS cannot start a second offer use 200 and get answer in ACK??

There is a conflict here.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 19 Feb 2002 17:02:00 +0200

Hello,

> This means that the UAS cannot start a second offer use 200 and get answer in ACK??

If at the same time that the UAS is sending a new offer in the 200 OK
the UAC is sending an UPDATE, we will have a glare condition. But the
UAC has no way of rejecting the offer in the 200 OK (SIP does not have a
NACK method). That's why this is disallowed.

Regards,

Gonzalo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Feb 2002 01:50:11 -0500

> This means that the UAS cannot start a second offer use 200 and get

Right, for the reasons Gonzalo has outlined. 

> There is a conflict here.

Indeed. I suspect my response, which you quote below, was sent before I
had fully worked it all out, or that I was just plain confused. Either
way, my apologies.

-Jonathan R.

> > > But for early media we use 180/PRACK to offer and answer the early
> media
> > > just before
> > >