Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP

[Peter Thatcher <[e-mail]>]

So, would you like a SessionDescription that is easy to read and
manipulate, such as a JSON object?

On Thu, Mar 7, 2013 at 1:22 PM, Silvia Pfeiffer
<[e-mail]> wrote:
> Agreed, but it's also not sufficient. SDP is not "programmer friendly"
> enough because it has too many details that are protocol-details only and
> it's too hard to see the semantic bits in SDP and ignore the rest.
>
> For example: the programmer wants to say - I want to get this video
> resolution, this audio bitrate & channels, I want to use this camera and
> this microphone for this call. Having to manipulate SDP directly for this is
> a programmer's nightmare.
>
> Silvia.
>
>
> On Fri, Mar 8, 2013 at 8:12 AM, Peter Thatcher <[e-mail]> wrote:
>>
>> You can already do that by "munging" the SDP.  It's just not very
>> pleasant to do.
>>
>> On Thu, Mar 7, 2013 at 1:09 PM, Silvia Pfeiffer
>> <[e-mail]> wrote:
>> > On Fri, Mar 8, 2013 at 5:51 AM, Mary Barnes <[e-mail]>
>> > wrote:
>> >>
>> >> On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla <[e-mail]> wrote:
>> >> >
>> >> > On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes
>> >> > <[e-mail]>
>> >> > wrote:
>> >> >>
>> >> >> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
>> >> >> <[e-mail]> wrote:
>> >> >> > Obviously I (and my employer) agree with these sentiments
>> >> >> > wholeheartedly.  Both Robin and Hadriel.
>> >> >> >
>> >> >> > That doesn't change the fact that a number of people are highly
>> >> >> > motivated to protect their investment in SDP offer/answer.  For
>> >> >> > those
>> >> >> > people, the pain that causes everyone else is clearly far less
>> >> >> > important than the pain they feel at this moment.  So here we are.
>> >> >>
>> >> >> [MB] I originally thought that either approach could work.  I did
>> >> >> see
>> >> >> the value that folks saw in using SDP offer/answer. But after
>> >> >> sitting
>> >> >> through the interim meeting last month, I am very much of the
>> >> >> mindset
>> >> >> that using SDP O/A is a bad idea.   I think many of us thought that
>> >> >> using the SDP blob would help with interoperability with "legacy"
>> >> >> SIP
>> >> >> endpoints.  I don't see that now at all.  I think we will end up
>> >> >> with
>> >> >> a very fragile solution that will be very difficult to extend/modify
>> >> >> later if we continue down the SDP O/A path.
>> >> >> [/MB]
>> >> >>
>> >> >
>> >> > Hasn't the WG already been asked this question not once but
>> >> > twice.
>> >> [MB] Yes.  And, some of us have changed our positions based upon the
>> >> challenges that the group is facing in getting the current approach
>> >> specified and agreed.  I don't disagree that it is not a good thing
>> >> that this is being discussed yet again.  [/MB]
>> >
>> >
>> > [Gotta love the triple negation!]
>> >
>> > Why can't we have it both ways?
>> >
>> > Maintain the current way to get the raw SDP using createOffer, but then
>> > provide an interface to change that offer before setLocalDescription.
>> >
>> > Even CISCO provides such an API:
>> >
>> > http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/sip_tn/8_5_1/4-sdp_api.html
>> > (I think we can do a better one than this, but it's a reference point).
>> >
>> > Cheers,
>> > Silvia.
>> >
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>
>