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

["Elwell, John" <john.elwell at siemens-enterprise.com>]

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