[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level
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:yekuiwang at huawei.com]
Sent: Tuesday, May 05, 2009 7:39 PM
To: 'Roni Even'; 'Elwell, John'; avt at ietf.org
Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile level
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
> -----Original Message-----
> From: Roni Even [mailto:ron.even.tlv at gmail.com]
> Sent: Tuesday, May 05, 2009 11:43 AM
> To: 'Ye-Kui Wang'; 'Elwell, John'; avt at ietf.org
> Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt -
> Profile level
>
> 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:yekuiwang at huawei.com]
> Sent: Tuesday, May 05, 2009 5:47 PM
> To: 'Elwell, John'; 'Roni Even'; avt at ietf.org
> Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt -
> Profile level
>
>
> 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
>
> > -----Original Message-----
> > From: Elwell, John [mailto:john.elwell at siemens-enterprise.com]
> > Sent: Tuesday, May 05, 2009 4:47 AM
> > To: Ye-Kui Wang; Roni Even; avt at ietf.org
> > Subject: RE: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt -
> > Profile level
> >
> > 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: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> > Behalf Of
> > > Ye-Kui Wang
> > > Sent: 04 May 2009 22:56
> > > To: 'Roni Even'; avt at ietf.org
> > > 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 problem
> > > and any need for change in the regard.
> > >
> > > BR,YK
> > >
> > >
> > > ________________________________
> > >
> > > From: avt-bounces at ietf.org
> > > [mailto:avt-bounces at ietf.org] On Behalf Of Roni Even
> > > Sent: Monday, May 04, 2009 5:09 PM
> > > To: avt at ietf.org
> > > Subject: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt -
> > Profile level
> > >
> > >
> > >
> > > From: Ashish Goyal
> > > Sent: Tuesday, May 05, 2009 12:04 AM
> > > To: 'avt at ietf.org'
> > > 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
> > >
> > >
> >
>
>
>