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

[Silvia Pfeiffer <[e-mail]>]

If your suggestion is only to convert the SDP to JSON, then that's a first
step, but not the full story, because the complexity is just represented in
a different format. I'm looking for something that helps programmers
achieve their goals more easily.

JSON is a first step, because it's a more readable data format. However, it
doesn't help me, to e.g. list the cameras on offer and remove one, or
change the offered video resolution. That needs manipulation functions.


On Fri, Mar 8, 2013 at 8:25 AM, Peter Thatcher <[e-mail]> wrote:

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