Subject: [AVT] Re: [Sip] RE: [Sip-implementors] media description in SDP is for sender or receiver?

From: Magnus Westerlund <[email-masked]>
Date: Fri, 04 Nov 2005 14:04:02 +0100

Hi,

(cc also AVT as this is an AVT WG matter)

It took AVT a long time until actually offer/answer sections started 
appearing in the RTP payload formats. It is basically only the last year 
or two that they have been included.

In general parameters applies for the stream the offerer/answer wants to 
receive. However config is a bit problematic. It provides information 
that concerns the bit-stream that the encoder will send out. Thus config 
applies from sender to receiver.

This is at least spelled out in RFC 3016:

"config: This parameter SHALL be used to indicate the configuration
       of the corresponding MPEG-4 Visual bitstream.  It SHALL NOT be
       used to indicate the codec capability in the capability exchange
       procedure."

So the interpretation I make is the following:
profile-level-id in an offer for a sendrecv stream tells the answerer 
the highest level and profile it may use to send media to the offerer.

The config string tells the answerer about the bit-stream it will 
receive from the offerer.

The issue with all parameters that relate to stream properties rather 
than capabilities or reception configurations that the receiver can 
determine for the sender is that they are based on assumptions about the 
other end-points capabilities. The offerer assumes that the answerer is 
at least as capable as the offerer and can handle the config string.

I think it is currently unspecified if the answerer may downgrade the 
received profile-level-id to a lower capability in its answer. I think 
that is reasonable, but it do generates some issues in regards to the 
config string. Because suddenly the config that the offerer provided may 
no longer be valid. The offerer would be forced to re-invite with a new 
offer that matches the answerer reception capabilities.

If one is interested in how terribly complicated this becomes should 
take a look at the H.264/MPEG AVC RTP payload format in RFC 3984.

RFC 3016 would benefit from an update to include the necessary 
offer/answer section that describe this. So volunteers are very welcome 
to start this work. Simply contact the authors and the AVT WG chairs.

As the above is my interpretation, if the interpretation made in 
implementations differ, then that fact should be commented on.

Cheers

Magnus Westerlund
AVT WG Chair

Ling, Fan wrote:
> 
> Since the "config=" field in my example is specific configuration for
> MPEG4 simple profile video bitstream, its interpretation should "depends
> on the parameters", however, I can't find such interpretation in MPEG4
> RTP RFC3016.
> 

-- 

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: "Ling, Fan" <[email-masked]>
Date: Mon, 7 Nov 2005 10:26:53 -0800

Magnus,
As you pointed out, inband transport of VOL headers may be one solution.
We also have explored this possibility. However, due to possible loss of
RTP packets, this may cause corrupted images for one whole GOP, which
can be several seconds long. 
It looks like the current standards don't have a satisfactory solution
to our problem. We are now looking for proprietary methods.
Thanks for your wonderful comments and advices.
Fan

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, November 07, 2005 5:45 AM
To: Ling, Fan
Cc: [email-masked]; [email-masked]; [email-masked];
IETF AVT WG
Subject: Re: [AVT] RE: [Sip] RE: [Sip-implementors] media description in
SDP is for sender or receiver?

Hi Ling,

See inline.

Ling, Fan wrote:
> Magnus,
> You are dead on on the issues we are concerned about. Initially, our
> understanding is the same as yours. However, when we proceed from
> one-to-one video telephony application to multiparty video conference
> application, the same understanding brings in some trouble.
> Let's assume "MPEG4 simple profile level 1" is the negotiated codec. 
> In one-to-one video telephony, both ends can use different video
sending
> parameters, that is, "config=" or VOL parameters, both ends decoder
just
> configure itself to the incoming video bitstream's setting. In
> multiparty conference, this means any one terminal has to configure
its
> multiple decoders according to different incoming bitstreams. This
makes
> the system a lot more complicated.

I don't see that you can avoid this. You anyway need to save the per 
stream decoder state, thus all active participants will result in state 
on the receiver side.

However isn't the real issue in multi-party that in many of the setup 
scenarios you are not able to describe in the answer more than a single 
configuration. Thus you are forced to use the inband transport that is 
not as robust.

> That's why we are coming back to the standards, to see whether there
is
> a rule that dictates that not only the codec type needs to be the
same,
> the video bitstream parameters (VOL) also needs to be the same for
both
> encoder and decoder.

To my knowledge this is not possible. However input from video coding 
experts are solicited.

Cheers

Magnus Westerlund