Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

From: "Roni Even" <[email-masked]>
Date: Tue, 5 May 2009 00:08:58 +0300

From: Ashish Goyal 
Sent: Tuesday, May 05, 2009 12:04 AM
To: [email-masked]'
Subject: draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level 

Hi, 

   I am leading an effort of sip video vendors under the aegis of IMTC Sip
video parity and working on a BCP document to enhance sip video
interoperability. In our discussion today there were some concerns around
the section 8.2.2 of 3984bis - specifically around the text

 "The level part of  "profile-level-id" is downgradable, i.e. the answerer
MUST  maintain the same or a lower level or remove the media format
(payload type) completely. "

 I am writing this mail in the hope that we can amend the 3984 bis so that
we can consider it as a reference - rather than having a conflicting BCP
document for video. 

   The recommendation from the group was to

1)      Consider level parameter as a declaration of receive capabilities
and not let it imply the resolution used for transmit

2)      Consider the level parameter as either upgradeable or downgradeable
- since it's really talking about receive capability. The answerer must not
transmit a level higher than the offer - but can provide an answer which
contains a level higher than the offer. This would allow the offerer to
transmit a higher level than it can receive - if it chooses to. 

  Here is  the issue that we are trying to address by having asymmetric
support for level. 

  One of the use cases which is well supported by some of the leading video
implementers is support for asymmetric video resolutions. The use case where
this becomes important is when the calls are made from a video softclient
running on  a pc.  Because of asymmetric compute requirements on encode and
decode - the video softclients would be able to typically decode much higher
resolution - than they are able to encode.  However section 8.2.2  makes
this negotiation difficult.  

 Here is how the use case is expected to work. 

  Assume the video device A is able to decode level 3.1 and encode only
level 1.1

  B is capable of both decoding and encoding level 3.1. 

  A would quote a level of 3.1 in its offer

  B would respond with level 3.1 in the answer

  A would send to B video stream at level 1.1 - since A can only encode at
level 1.1. 

  B would send level 3.1 to A since A can decode upto level 3.1.

Regards, 

Ashish

---

From: Ye-Kui Wang <[email-masked]>
Date: Mon, 04 May 2009 17:55:46 -0400

Hi,
 
The current design in the bis draft (as well as in in RFC 3984) does allow
negotiation of asymmetric video solutions using SDP offer/answer. What you
need to do is just to separate the sending part (a=sendonly) and the
receiving part (=recvonly) in the SDP. Therefore, I don't think there is any
problem and any need for change in the regard. 
 
BR,YK

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: Monday, May 04, 2009 5:09 PM
To: [email-masked]
Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

From: Ashish Goyal 

Hi, 

 

Regards, 

Ashish

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 05 May 2009 09:46:42 +0100

YK,

If I understand correctly, you would have two m-lines, one a=sendonly
(on which a lower bandwidth is negotiated, say), and one a=recvonly (on
which a higher bandwidth is negotiated, say)? This would really
complicate things. For example, I think you would need to assign two
different labels (a=label attribute), because I don't think the use of
the same label for two m-lines is defined. How would you refer to them
for floor control purposes? Also you would need to convey two a=crypto
lines for security descriptions if using SRTP. It would also complicate
NAT traversal, e.g., if using ICE, I think you would need to treat them
as two separate media.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ye-Kui Wang
> Sent: 04 May 2009 22:56
> To: 'Roni Even'; [email-masked]
> Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - 
> Profile level
> 
> Hi,
>  
> The current design in the bis draft (as well as in in RFC 
> 3984) does allow negotiation of asymmetric video solutions 
> using SDP offer/answer. What you need to do is just to 
> separate the sending part (a=sendonly) and the receiving part 
> (=recvonly) in the SDP. Therefore, I don't think there is any 
> ________________________________
> 
> 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Roni Even
> 	   I am leading an effort of sip video vendors under 
> the aegis of IMTC Sip video parity and working on a BCP 
> document to enhance sip video interoperability. In our 
> discussion today there were some concerns around the section 
> 8.2.2 of 3984bis - specifically around the text
> 
> 	 
> 
> 	 "The level part of  "profile-level-id" is 
> downgradable, i.e. the answerer MUST  maintain the same or a 
> lower level or remove the media format  (payload type) completely. "
> 
> 	 
> 
> 	 I am writing this mail in the hope that we can amend 
> the 3984 bis so that we can consider it as a reference - 
> rather than having a conflicting BCP document for video. 
> 
> 	 
> 
> 	1)      Consider level parameter as a declaration of 
> receive capabilities and not let it imply the resolution used 
> for transmit
> 
> 	2)      Consider the level parameter as either 
> upgradeable or downgradeable - since it's really talking 
> about receive capability. The answerer must not transmit a 
> level higher than the offer - but can provide an answer which 
> contains a level higher than the offer. This would allow the 
> offerer to transmit a higher level than it can receive - if 
> it chooses to. 
> 
> 	 
> 
> 	  Here is  the issue that we are trying to address by 
> having asymmetric support for level. 
> 
> 	 
> 
> 	  One of the use cases which is well supported by some 
> of the leading video implementers is support for asymmetric 
> video resolutions. The use case where this becomes important 
> is when the calls are made from a video softclient  running 
> on  a pc.  Because of asymmetric compute requirements on 
> encode and decode - the video softclients would be able to 
> typically decode much higher resolution - than they are able 
> to encode.  However section 8.2.2  makes this negotiation difficult.  
> 
> 	 
> 
> 	  Assume the video device A is able to decode level 3.1 
> and encode only level 1.1
> 
> 	  A would send to B video stream at level 1.1 - since A 
> can only encode at level 1.1. 
>

---

From: "Jonathan Lennox" <[email-masked]>
Date: Tue, 5 May 2009 10:19:29 -0400

I agree with John's analysis of Ye-Kui's statement -- trying to do
asymmetric media using separate m= lines isn't very practical for a
number of reasons.

That said, though I think it would be cleaner to have purely
receive-only semantics for profile-level-id, I have trouble imagining
situations for which the current specification is problematic.  The
profile-level-id parameter only gives an upper bound on what the
bitstream can contain; it's always valid to send a bitstream that uses a
lower (more constrained) profile and level than what was negotiated.

Thus, I don't see a problem unless an endpoint wants to encode using a
*higher* profile or level than it's able to decode.  I suppose this
could happen for pre-encoded video, hardware-assisted encoding, or the
like, but it certainly seems like a more unusual case for bi-directional
media.

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

> From: Elwell, John [mailto:[email-masked]]
> Sent: Tuesday, May 05, 2009 4:47 AM
> To: Ye-Kui Wang; Roni Even; [email-masked]
> Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile
level
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 05 May 2009 10:40:25 -0400

I don't see a technical reason why the level part was not specified as a
capability parameter in the beginning. However, now it is too late because
there are already a huge amount of RFC 3984 implementations taking the level
part in the way as specified in RFC 3984 and the bis draft. Unless something
is broken, we should not make a change that is not backward compatible,
because that will hurt interoperability instead of making better
interoperability.
 
BR, YK

  _____  

From: Ashish Goyal [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 11:01 PM
To: Ye-Kui Wang; Roni Even; [email-masked]
Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

The sendonly and recvonly is normally not handled well by some
proxies/session border controllers and some UAs. While technically it's
possible to do that - it's however not interoperable implementation. 

Is there a specific reason why the level part is considered  non
upgradeable?

Ashish

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ye-Kui
Wang
Sent: Tuesday, May 05, 2009 3:26 AM
To: 'Roni Even'; [email-masked]
Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

Hi,

BR,YK

  _____  

From: Ashish Goyal 

Hi, 

 

Regards, 

Ashish

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 05 May 2009 10:47:12 -0400

John,

Yes, your understanding is correct, I meant use of two m-lines. While that
is not perfect, I believe changing this fundamental part in a
non-backward-compatible way would be much worse, as I explained in the
previous email. Making the change can only help to enable asymmetric video
solutions more conveniently, but would basically disable communications
between any legacy implementation of new implementations. In addition, there
might be a technical reason, which I don't know, duing the development of
RFC 3984 for the current specification of the level part. 

BR, YK 

> If I understand correctly, you would have two m-lines, one 
> a=sendonly (on which a lower bandwidth is negotiated, say), 
> and one a=recvonly (on which a higher bandwidth is 
> negotiated, say)? This would really complicate things. For 
> example, I think you would need to assign two different 
> labels (a=label attribute), because I don't think the use of 
> the same label for two m-lines is defined. How would you 
> refer to them for floor control purposes? Also you would need 
> to convey two a=crypto lines for security descriptions if 
> using SRTP. It would also complicate NAT traversal, e.g., if 
> using ICE, I think you would need to treat them as two separate media.
> 
> John
> 
> 
> Behalf Of 
> > Ye-Kui Wang
> using SDP 
> > offer/answer. What you need to do is just to separate the 
> sending part 
> > (a=sendonly) and the receiving part
> > (=recvonly) in the SDP. Therefore, I don't think there is 
> any problem 
> > and any need for change in the regard.
> >  
> > BR,YK
> > 
> >

---

From: "Roni Even" <[email-masked]>
Date: Tue, 5 May 2009 18:43:02 +0300

YK,
RFC3984bis did change the behavior concerning the level symmetry. We decided
that the level can be downgraded because we thought as far as I remember
that there was no reason to answer with higher level since the offerer said
it cannot support higher level while lower level is implicit
I can understand that it does not matter if the answer has higher level
since the answerer will still need to send within the offered level but the
offerer can send at higher level if it can.

Roni

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Tuesday, May 05, 2009 5:47 PM
To: 'Elwell, John'; 'Roni Even'; [email-masked]
Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

John,

BR, YK

---

From: "Roni Even" <[email-masked]>
Date: Tue, 5 May 2009 18:44:18 +0300

Jonathan,
I think that only the level can be downgraded not the profile
Roni

-----Original Message-----
From: Jonathan Lennox [mailto:[email-masked]] 
Sent: Tuesday, May 05, 2009 5:19 PM
To: Elwell, John; Ye-Kui Wang; Roni Even; [email-masked]
Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

level

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 05 May 2009 12:39:22 -0400

Roni,

The issue here (asymmetry use of level, or more specificically spatial
resolution, in sending and receiving) is different from level downgrade. The
level downgrade concept is that the answerer can answer an offer SDP with a
lower level, and then the lower level is what is agreed. While what was
suggested, if I understand correctly, is to have no restriction on the
indicated level in an answer, i.e. it can be equal, lower or higher than the
indicated level in the offer. 

BR,YK 

> From: Roni Even [mailto:[email-masked]] 
> Sent: Tuesday, May 05, 2009 11:43 AM
> To: 'Ye-Kui Wang'; 'Elwell, John'; [email-masked]
> RFC3984bis did change the behavior concerning the level 
> symmetry. We decided that the level can be downgraded because 
> we thought as far as I remember that there was no reason to 
> answer with higher level since the offerer said it cannot 
> support higher level while lower level is implicit I can 
> understand that it does not matter if the answer has higher 
> level since the answerer will still need to send within the 
> offered level but the offerer can send at higher level if it can.
> 
> Roni
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 5 May 2009 20:04:43 +0300

YK,
This is also what I understand and my comment was saying that I am not sure
why we have only downgrade in the answer in 3984bis. The downgrade option
was added in 3984bis, in rfc3984 you had to have the same level in the
answer.
Roni

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Tuesday, May 05, 2009 7:39 PM
To: 'Roni Even'; 'Elwell, John'; [email-masked]
Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

Roni,

BR,YK

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 05 May 2009 14:44:00 -0400

Roni,

My understanding is that in RFC 3984 the intention was to allow for level
downgrade in SDP offer/answer, but there is some inconsistence in that
regard and the bis draft clarified the issue. 

BR, YK 

> Sent: Tuesday, May 05, 2009 1:05 PM
> This is also what I understand and my comment was saying that 
> I am not sure why we have only downgrade in the answer in 
> 3984bis. The downgrade option was added in 3984bis, in 
> rfc3984 you had to have the same level in the answer.
> Roni
>

---

From: Tom Kristensen <[email-masked]>
Date: Tue, 5 May 2009 21:52:52 +0200

Yes, existing RFC3984 implementations did already implement a policy
allowing level downgrade when building the answer. The bis draft
formalizes this behaviour. The profile part had to be kept fixed back
then, now and for all future.

However, as the level specify receive capabilities and are
downgradable I understand the request and wish to upgrade the level -
i.e. indicate a "better" ability to decode the stream in the answer
than specified by the peer in the offer. Using separate media line
with sendonly and recvonly direction attributes is not a good solution
at all.

-- Tom

-- 
# TANDBERG R&D
## http://www.tandberg.com
### http://folk.uio.no/tomkri/

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 06 May 2009 16:42:30 +0200

Ye-Kui Wang skrev:
> capability parameter in the beginning. However, now it is too late
> because there are already a huge amount of RFC 3984 implementations
> taking the level part in the way as specified in RFC 3984 and the bis
> draft. Unless something is broken, we should not make a change that is
> not backward compatible, because that will hurt interoperability instead
> of making better interoperability.

When it comes to RFC 3984 definition, the intention, but which I screwed
up in defining was that the profile needs to be symmetric, but the level
can be changed.

This is a thorny issue, and if you want asymmetric behavior you will
need to have separate capability and actual transmission configuration
in the  SDP.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Roni Even" <[email-masked]>
Date: Wed, 6 May 2009 18:14:24 +0300

Hi Magnus,
I think the question that Ashish is trying to ask is not about general
asymmetry. The level parameter is signaling a maximum since it implies
support for any level below the on in the offer. The level specifies the
maximum that the offerer can send and receive. The answerer should except to
receive a stream that is in the level in the offer.
Now the answer can reply with a level lower than the one in the offer. Now
the offer should send a stream that is within the level in the answer since
by signaling a specific level it implies that a lower one is also possible.
Still the answerer can send a stream that is within the level signaled by
the offer even though it gave a lower level - this is already asymmetry. The
problem is that the current text says that the level signals the level that
the answerer can receive but also that it can send but the above description
hints that asymmetry may happen even now.

Ashish is asking why for the case of offer answer, if the above analysis is
correct why not allow the answerer to specify a level higher than the one in
the offer since it will still have similar result to the case when the
answer has a level lower than the offer.  

And I agree that the implementation today for the offer answer case follow
draft 3984bis

Roni

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2009 5:43 PM
To: Ye-Kui Wang
Cc: 'Ashish Goyal'; 'Roni Even'; [email-masked]
Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

Cheers

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: Wed, 06 May 2009 17:11:37 -0400

>regard and the bis draft clarified the issue. 

That's correct - Level downgrade was unofficially added/clarified long
before the 3984bis effort began.

Note that level upgrade would interact (yet again!) with
sprop-parameter-sets, though the solution found for 3984bis should work.
(I haven't worked out hte use cases; just a gut feeling that it will work.)

As mentioned, it would seem that level upgrade would only help in the case
of an endpoint that can encode at a higher level than it can/is willing to
decode.

If encode level == decode level, then offer that.  Note that hardware may
be able to in theor decode a higher level, but the device may not be able
to use the extra resolution and/or framerate.

If encode level < decode level (common), then offer the decode level, and
send using the encode level.  There are some gotchas with this though:
   a) We're assuming the answerer understands how to level-downgrade
   b) If using sprop-parameter-sets, we'll want to offer parameter sets for
      multiple levels (as per 3984bis).  Care will need to be taken to
      ensure compatibility with 3984 endpoints (as is the norm for 3984bis).

   This is basically normal 3984bis activity.

If encode level > decode level (odd - the only cases I can think of that
makes sense are: hardware encoder but no hw decoder (weird); pre-encoded
outbound video (unusual case); larger sensor than display (example: 1MP
sensor and encode ability, but a 640x480 display) - this is the only
likely case.  I suggest in that case, if possible, implement a post-decode
scale and offer the encode level.  If that's not sufficient, then we have
the tough case.  Options are:
   a) level upgrade on answer (not currently allowed, and now being requested)
   b) limit answer to offer (wastes camera resolution)
   c) use two m= lines - but this is an "answer" case, and we can't *add*
      m-lines, so this only works if two were offered, so this really
      doesn't help much.  Also, if offering two m= lines, you're likely to
      have real problems with devices that *don't* know how you're using
      the two streams.  Almost all devices will ignore the second stream.

My suggestion: offer the encoder level, and scale any received video.  It's
not an optimum solution, but it retains much more compatibility that other
solutions.

Alternate if you really want to save bits: add an extension in an offer to
the fmtp, level-upgrade-allowed=1.  We *could* add that to 3984bis without
too many nasty ramifications, I think.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 06 May 2009 18:17:30 -0400

If level upgrade in SDP answer is allowed in the bis draft, then if the
offerer is a legacy device, it may consider the answer as illegal. Is the
benefit of allowing this big enough to compensate the introduced
interoperability issue?

BR,YK 

> From: Randell Jesup [mailto:[email-masked]] 
> Sent: Wednesday, May 06, 2009 5:12 PM
> To: Ye-Kui Wang
> Cc: 'Roni Even'; 'Elwell, John'; [email-masked]
> >My understanding is that in RFC 3984 the intention was to allow for 
> >level downgrade in SDP offer/answer, but there is some 
> inconsistence in 
> >that regard and the bis draft clarified the issue.
> 
> That's correct - Level downgrade was unofficially 
> added/clarified long before the 3984bis effort began.
> 
> As mentioned, it would seem that level upgrade would only 
> help in the case of an endpoint that can encode at a higher 
> level than it can/is willing to decode.
> 
> If encode level == decode level, then offer that.  Note that 
> hardware may be able to in theor decode a higher level, but 
> the device may not be able to use the extra resolution and/or 
> framerate.
> 
> If encode level < decode level (common), then offer the 
> decode level, and send using the encode level.  There are 
> some gotchas with this though:
> If encode level > decode level (odd - the only cases I can 
> think of that makes sense are: hardware encoder but no hw 
> decoder (weird); pre-encoded outbound video (unusual case); 
> larger sensor than display (example: 1MP sensor and encode 
> ability, but a 640x480 display) - this is the only likely 
> case.  I suggest in that case, if possible, implement a 
> post-decode scale and offer the encode level.  If that's not 
> sufficient, then we have the tough case.  Options are:
> My suggestion: offer the encoder level, and scale any 
> received video.  It's not an optimum solution, but it retains 
> much more compatibility that other solutions.
> 
> Alternate if you really want to save bits: add an extension 
> in an offer to the fmtp, level-upgrade-allowed=1.  We *could* 
> add that to 3984bis without too many nasty ramifications, I think.
> 
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), 
> ex-Amiga OS team [email-masked] "The fetters imposed on 
> liberty at home have ever been forged out of the weapons

---

From: Randell Jesup <[email-masked]>
Date: Wed, 06 May 2009 22:02:28 -0400

>benefit of allowing this big enough to compensate the introduced

There's no legacy issue if level upgrade is enabled by the offerer adding
"level-upgrade-allowed=1" (or if there's something else the answer can key
off).  If the offerer included that, they support it.  If not (or 0), the
answerer must not upgrade the level.

If we decide to do something like this, we could either require supporting
level upgrade always (MUST add the fmtp parameter if you're
3984bis-compliant), or allow it only when the offerer wants to support it
(add it at the discretion of the offerer).

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 06 May 2009 22:12:05 -0400

Furthermore, to use one m= line to represent different levels (as
capabilities) for sending and receiving, you would need two level
parameters. 

BR, YK

> Sent: Wednesday, May 06, 2009 6:18 PM
> To: 'Randell Jesup'
> Cc: [email-masked]
> If level upgrade in SDP answer is allowed in the bis draft, 
> then if the offerer is a legacy device, it may consider the 
> answer as illegal. Is the benefit of allowing this big enough 
> to compensate the introduced interoperability issue?
> 
> BR,YK 
> 
> > (I haven't worked out hte use cases; just a gut feeling 
> that it will 
> > work.)
> > 
> help in the 
> > case of an endpoint that can encode at a higher level than 
> it can/is 
> > willing to decode.
> > 
> > If encode level == decode level, then offer that.  Note 
> that hardware 
> > may be able to in theor decode a higher level, but the 
> device may not 
> > be able to use the extra resolution and/or framerate.
> > 
> decode level, 
> > and send using the encode level.  There are some gotchas with this 
> > though:
> > If encode level > decode level (odd - the only cases I can think of 
> > that makes sense are: hardware encoder but no hw decoder (weird); 
> > pre-encoded outbound video (unusual case); larger sensor 
> than display 
> > (example: 1MP sensor and encode ability, but a 640x480 
> display) - this 
> > is the only likely case.  I suggest in that case, if possible, 
> > implement a post-decode scale and offer the encode level.  
> If that's 
> > not sufficient, then we have the tough case.  Options are:
> received video.  
> > It's not an optimum solution, but it retains much more 
> compatibility 
> > that other solutions.
> > 
> > Alternate if you really want to save bits: add an extension in an 
> > offer to the fmtp, level-upgrade-allowed=1.  We *could* add that to 
> > 3984bis without too many nasty ramifications, I think.
> > 
> > --
> > Randell Jesup, Worldgate (developers of the Ojo 
> videophone), ex-Amiga 
> > OS team [email-masked] "The fetters imposed on liberty at 
> home have 
> > ever been forged out of the weapons provided for defence 
> against real, 
> > pretended, or imaginary dangers from abroad."

---

From: Randell Jesup <[email-masked]>
Date: Thu, 07 May 2009 09:41:53 -0400

>capabilities) for sending and receiving, you would need two level

This is no different than supporting level downgrade.  If you're using
in-band parameter sets, those carry the actual level within them.  If
you're using out-of-band parameter sets, those are "send" parameters.  So
an offerer who supports allow-level-upgrade=1 would include in
sprop-level-parameter-sets levels above the offer level, up to the maximum
sending level the offerer supports.

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 07 May 2009 10:59:57 -0400

The word "parameters in "two level parameters" did not mean "parameter sets"
:-)

To establish an asymmetric (in spatial resolution and level) video
communication session between two entities, wherein one side wants to send
at a lower level (say, QCIF) but receive at a higher level (say, CIF), while
the other side wants to send at CIF and receive at QCIF. Then both the offer
and the answer should contain two level parameters, level_a and level_b
(level_a < level_b), to indicate the sending and receiving (or reversely)
capabilities (or preferences). 

Simply adding allow-level-upgrade is not clear to me. Assuming that both
sides indicate allow-level-upgrade = 1. If the answer contains a higher
level, then what is the highest level to use in the direction from the
offerer to the answerer and what is the highest level to use in the other
direction? The same question applies when the answer contains a lower level.

BR, YK 

> Sent: Thursday, May 07, 2009 9:42 AM
> To: Ye-Kui Wang
> Cc: [email-masked]
> This is no different than supporting level downgrade.  If 
> you're using in-band parameter sets, those carry the actual 
> level within them.  If you're using out-of-band parameter 
> sets, those are "send" parameters.  So an offerer who 
> supports allow-level-upgrade=1 would include in 
> sprop-level-parameter-sets levels above the offer level, up 
> to the maximum sending level the offerer supports.
> 
> --

---

From: "Roni Even" <[email-masked]>
Date: Thu, 7 May 2009 18:28:15 +0300

YK,
I think that the issue is not to establish an asymmetric communication where
one sides sends qcif and the other cif. Using the level in the offer answer
will not help for that since the level is a maximum so even if the offer
says it can receive CIF the answerer can send him a qcif picture.
What Ashish wants is to be able to declare a higher level in the answer. You
can see the other thread I had with Magnus, I think it explains it better.
For the case when an endpoint wants to receive a specific picture size you
will need some request mechanism, example is by the image attribute draft in
mmusic

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ye-Kui
Wang
Sent: Thursday, May 07, 2009 6:00 PM
To: 'Randell Jesup'
Cc: [email-masked]
Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level

BR, YK

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 07 May 2009 11:39:30 -0400

Roni,

I understand. Note my wording of "the highest level".

BR, YK

> Sent: Thursday, May 07, 2009 11:28 AM
> To: 'Ye-Kui Wang'; 'Randell Jesup'
> Cc: [email-masked]
> I think that the issue is not to establish an asymmetric 
> communication where one sides sends qcif and the other cif. 
> Using the level in the offer answer will not help for that 
> since the level is a maximum so even if the offer says it can 
> receive CIF the answerer can send him a qcif picture.
> What Ashish wants is to be able to declare a higher level in 
> the answer. You can see the other thread I had with Magnus, I 
> think it explains it better.
> For the case when an endpoint wants to receive a specific 
> picture size you will need some request mechanism, example is 
> by the image attribute draft in mmusic
> 
> Roni
> 
> To establish an asymmetric (in spatial resolution and level) 
> video communication session between two entities, wherein one 
> side wants to send at a lower level (say, QCIF) but receive 
> at a higher level (say, CIF), while the other side wants to 
> send at CIF and receive at QCIF. Then both the offer and the 
> answer should contain two level parameters, level_a and 
> level_b (level_a < level_b), to indicate the sending and 
> receiving (or reversely) capabilities (or preferences). 
> 
> Simply adding allow-level-upgrade is not clear to me. 
> Assuming that both sides indicate allow-level-upgrade = 1. If 
> the answer contains a higher level, then what is the highest 
> level to use in the direction from the offerer to the 
> answerer and what is the highest level to use in the other 
> you're using 
> > you're using out-of-band parameter sets, those are "send" 
> parameters.  
> > So an offerer who supports allow-level-upgrade=1 would include in 
> > sprop-level-parameter-sets levels above the offer level, up to the 
> > maximum sending level the offerer supports.
> > 
> > --

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 07 May 2009 17:01:28 +0200

> hints that asymmetry may happen even now.

Yes, I agree that for this type of parameter in offer/answer you would
declare your receiver capability. So what you say is right.

> answer has a level lower than the offer.  

Yes, that is true.

Cheers

Magnus Westerlund