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

[Ye-Kui Wang <yekuiwang at huawei.com>]

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