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

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 6 May 2009 08:02:41 +0200

Hi

In 
http://tools.ietf.org/id/draft-johansson-mmusic-asymmetric-media-00.txt

I proposed an extension to SDP*CapNeg to make it possible to negotiate
asymmetric sessions, not only video but also for various audio setups
where asymmetry is an issue. I did not get any comments on the list but
had a lengthy discussion about the pros and cons with Bob Gilman (Bob,
please feel free to speak up :-)

The extension builds on SDP*CapNeg but is not anymore backwards
compatible in the SDPCapNeg way as one cannot formulate an answer SDP
with a conventional SDP.
There is however a backwards compatibility in the sense that an enpoint
that does not understand the asymmetric extension will fall back to the
symmetric version.

Regarding 3984bis, there is also a comment in the doc that said draft
already has some support for asymmetry.

Regards
Ingemar

PS   SDP*CapNeg = SDP Capability Negotiation and SDP Media Capabilities
Negotiation
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 04 May 2009 17:55:46 -0400
> From: Ye-Kui Wang <[email-masked]>
> Subject: Re: [AVT] draft-ietf-avt-rtp-rfc3984bis-06.txt - Profile
> 	level
> To: 'Roni Even' <[email-masked]>, [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
> 
> 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
> 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
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://www.ietf.org/mail-archive/web/avt/attachments/20090504
/07682d78/attachment.htm>