Subject: [AVT] Soliciting comments on Offer/Answer procedures

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 May 2004 16:21:40 +0200

Hi,

Any reply to this mail should be directed to the AVT mailing list. The 
mail is BCC to MMUSIC, SIP and SIPPING to avoid cross postings.

In the RTP payload format for the H.264/AVC video codec, we authors had 
to write a rather special procedure in the offer/answer. This procedure 
is there to make the distribution of the video codecs parameter sets 
work. However we would like to have further review from people knowing 
SIP and Offer/Answer thoroughly, to ensure that we have not created any 
problems.

Therefore I would be very thankful if you could take a look at:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-06.txt

and review the Offer/Answer consideration section (8.2). I wouldn't 
expect that you will need to read more than some further parts of 
section 8, and possibly some of the introduction in section 1 for 
background information.

Any comments is desired within two weeks, i.e. before 9th of June.

Thanks

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 19 May 2004 11:07:36 +0300

Magnus,

I have just had a look at the offer/answer section of the draft. Using 
three extra parameters to identify the media format in addition to the 
rtpmap name is OK.

Regarding the parameters "parameter-sets", "deint-buf-req", 
"interleaving-depth", "max-don-diff", and "init-buf-time", describe what 
the generator of the session description will *send*. Since, as it is 
pointed out by the draft, this behavior is not standard offer/answer, I 
would rename the parameters so that their meaning is clearer. Adding the 
prefix "sending", for instance, would be enough. We would have 
"sending-parameter-sets", "sending-deint-buf-req", etc...

It would be useful to add an introductory paragraph explaining that the 
offer/answer model assumes that when an offerer requests an answerer to 
use a random combination of parameters for a given media stream, the 
answerer will be able to use those parameters. Nevertheless, when we 
deal with H.264 the situation is different, because a sender only 
supports certain combinations of parameters.

I would rephrase the following paragraph as follows:

OLD:
"This differs from
       the normal usage of the offer/answer parameters: normally such
       parameters declare the properties of the stream the
       offerer/answerer is going to receive.  The offerer MUST assume
       that the answerer supports the same configuration and basic
       capabilities that it is offering."

NEW:
"This differs from
       the normal usage of the offer/answer parameters: normally such
       parameters declare the properties of the stream the
       offerer or the answerer is going to receive. When dealing with 
H.264, the offerer assumes that the answerer will be able to receive 
media encoded using the configuration being offered."

Regarding the following paragraph:
"To simplify handling and matching of these configurations, the
       same RTP payload type number used in the offer SHOULD also be used
       in the answer. "

This rule is already mentioned in RFC 3264.

"In the case of RTP, if a particular codec was referenced with a
    specific payload type number in the offer, that same payload type
    number SHOULD be used for that codec in the answer."

You may want to reference RFC 3264 in that paragraph so that is it clear 
that you are not specifying a special rule but that you are referencing 
an already existing general rule.

Cheers,

Gonzalo

Magnus Westerlund wrote:

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