The following is the summary of disucssion on this.

 

The way for setting codec preferences will be through RTCRtpSender/Receiver.

This setting will just set the preferences and will not modify the ongoing encoding codec.

The specified preferences of codecs will be considered when createOffer/Answer is invoked for the next time.

 

Regards,

Kiran.

 

------- Original Message -------

Sender : Kiran Kumar Guduru<kiran.guduru@samsung.com> Lead Engineer/SRI-Bangalore-TZN/Samsung Electronics

Date : May 20, 2014 00:20 (GMT+09:00)

Title : Re: Re: Re: Re: Avoid sdp mangling in WebRTC by setting codec preferences - review request.

 

Justin,

Thanks for your suggestions and comments.

 

As I already specified, I am not opposing to set preferences through RTCRtpSender/Receiver API.

I am more interested to set the preferences through API and avoid SDP mangling.

As suggested by you, I will modify the draft to reformulate it in terms of RTCRtpSender/Receiver along with the usecase.

 

Regards,

Kiran.


 

------- Original Message -------

Sender : Justin Uberti<juberti@google.com>

Date : May 19, 2014 23:08 (GMT+09:00)

Title : Re: Re: Re: Avoid sdp mangling in WebRTC by setting codec preferences - review request.

 




On Mon, May 19, 2014 at 6:41 AM, Kiran Kumar Guduru <kiran.guduru@samsung.com> wrote:

Hi,

Please find my comments inline.

 

------- Original Message -------

Sender : Justin Uberti<juberti@google.com>

Date : May 19, 2014 02:26 (GMT+09:00)

Title : Re: Re: Avoid sdp mangling in WebRTC by setting codec preferences - review request.

 

This is a slippery slope towards full capabilities introspection from JS. I'm not opposed to that, but it's clearly not in scope for 1.0.
 
[KIRAN] I might be bit late to suggest this, but I hope it is good to move this in webrtc1.0 to avoid risky SDP Mangling.

Also, the use of createOffer options to specify the preferences is the wrong place. I think the right place for this control surface would be on the RTCRtpSender/Receiver object, as that avoids the need for separate audio and video APIs, and lets the codecs be controlled per-track.
 

[KIRAN] The reason for proposing this in createOffer instead of RTCRtpSender/Receiver is as follows.

 

1. To reduce the changes that may require in existing API, because of this API (if any). 

2. To be almost in sync with the existing approach. i.e., we are changing the codec preferences now after createOffer, which will be moved just before that.

3. For having multiple m= lines, for example to support multiple video on a single connection (m= lines for each video stream in SDP), we can pass different sequences of preferedVideoCodecs in options.

    The same can be attained by using RTCRtpSender/Receiver. I am not opposing it, but there is a small chance that may in ambiguity in this case which made me to consider createOffer-options.

    For setting preferences using RTCRtpSender/Receiver, we have to set them in both Sender and Receiver (which starts encoder and decoder respectively). If by mistake order of codecs got changed between Sender and Receiver, then it will result in error scenario. This sort of issues may occur when multiple video/ audio are used.


What do you expect preferredXXXXCodecs to do? My understanding was that it just would rearrange the order of codecs in createOffer. If so, this only affects the RtpReceiver.

Adding multiple sets of options for each m= line to createOffer is a non-starter; RtpReceiver is being added to avoid this sort of thing. If you want this proposal to be considered, please reformulate it in terms of RtpReceiver.

I also suggest you add a use case to your document to make it clear what it is trying to accomplish.

 

Regards,

Kiran.

On Sun, May 18, 2014 at 6:38 AM, Kiran Kumar Guduru <kiran.guduru@samsung.com> wrote:

Hi,

 

http://tools.ietf.org/html/draft-guduru-ietf-rtcweb-codec-preferences-00

has been replaced with

http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-00

 

Only name change, to make it appear in recweb related documents list in rtcweb status pages.

 

Kiran.

 

------- Original Message -------

Sender : Cullen Jennings<fluffy@iii.ca>

Date : May 18, 2014 22:18 (GMT+09:00)

Title : Re: Avoid sdp mangling in WebRTC by setting codec preferences - review request.

 


Iíve forwarded this to the webrtc group instead of rtcweb as I suspect that is also a good place to discuss it.


On May 16, 2014, at 11:03 AM, Kiran Kumar Guduru wrote:

> Dear Chairs,
> I published an ietf drat related to RTCWEB wrok draft-guduru-ietf-rtcweb-codec-preferences-00.
> The intention of this draft is to avoid SDP mangling.
> It extends the RTCPeerConnection to allow JS application to set the codec preferences, instead of doing it through SDP mangling.
> When I read the JSEP spec, I find that codec preferences is the only thing that requires SDP mangling, but remaining cases we can manage with constraints.
> I hope this draft will be very helpful to make WebRTC more robust and will become a working group draft soon.
> I request you in person to review the draft and let me know your comments.
> The following is the link for the same.
> http://tools.ietf.org/html/draft-guduru-ietf-rtcweb-codec-preferences-00
>  
Ö snip Ö
>  
> Have a Nice Day,
> Kiran.
>  
> <201405162033058_Z7RK8XTA.gif>