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

Silvia Pfeiffer <silviapfeiffer1@gmail.com> Thu, 07 March 2013 21:31 UTC

Return-Path: <silviapfeiffer1@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4482121F852B for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 13:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onHWosrSBVvy for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 13:31:15 -0800 (PST)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BEB0E21F8168 for <rtcweb@ietf.org>; Thu, 7 Mar 2013 13:31:14 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id fe20so1029464lab.1 for <rtcweb@ietf.org>; Thu, 07 Mar 2013 13:31:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5Jq1vT+oVuud6WtRG2qnje8+Db8RPIfmTQyeA91f8DE=; b=pFNC2Zud4dYFSHIOI3uHgd3oD2NFdjb/7AV3zWoRX7XEaYjRBH2AQKpw2hEp1jZEmN 8nHwDEctVt5VBOgwjmRhkfDJsjMDGrBoXxEzw/yDLljeWuwaMGIXTMTvCOaAuc4ZRDJq eQb6KWwmZlrwy4S0SYUm2kqQnGPmDMlb/esVDmDMLyA6ZBIs+GXNRZ6JP6K6B1/AIU+L /hIhsWksUeDmBvedORj6pTjqpNkb+ILzw8B4upGOziP6uJPl0EJeoEdRzqNi4Iw2pUhn hOQxdR7AlSOVKcE0OnvFFpKcFPSIzqM00YMOaFTP/wnOIN1hmNLp3Lsonp2WyU9uCIV2 sZiA==
X-Received: by 10.152.134.40 with SMTP id ph8mr29678970lab.39.1362691873725; Thu, 07 Mar 2013 13:31:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.51.229 with HTTP; Thu, 7 Mar 2013 13:30:52 -0800 (PST)
In-Reply-To: <CAJrXDUF2o0sgTq-f30vRYU0Hrx_bKUkb5eaGkLoE1ysXvfdN7w@mail.gmail.com>
References: <CD5D3F35.B22B%robin@hookflash.com> <B9549E2E-6E68-4F34-A9C0-1F050285A70A@acmepacket.com> <CABkgnnXCio-Dw7dN5yfSjeRf3wG2oWow_M2mU-Y49TedSAPQmg@mail.gmail.com> <CAHBDyN6CFTix3W9qWgC1T0O36t4SajL3hMXaHOdkat-p5TY_xA@mail.gmail.com> <CABcZeBMLdEkFZq5rMOY0texKb4DtFQ-O86JkC17kJihxv6Dj8w@mail.gmail.com> <CAHBDyN6mM-rT315uSbeTQfKuCiVwsEDhi7Q6DEbt8pjiJ_4i6g@mail.gmail.com> <CAHp8n2nz=NZb=UaevUSS7GRSBpvn-v9_=QHz6iddnZzyx5-TSQ@mail.gmail.com> <CAJrXDUETwfY7ZvaXO_1Bq8gs8pOTgALQE8FiimrUX7sfuEpDsw@mail.gmail.com> <CAHp8n2kcEHcz11LOYYMZ3-nv2PYQKu=z6M=dsQ_H5JuR8ND7hQ@mail.gmail.com> <CAJrXDUF2o0sgTq-f30vRYU0Hrx_bKUkb5eaGkLoE1ysXvfdN7w@mail.gmail.com>
From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 8 Mar 2013 08:30:52 +1100
Message-ID: <CAHp8n2mqQvAcVb3Mc6pbGoCOtPeFG+dRM6BaEVVqpEBZao7N9g@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Content-Type: multipart/alternative; boundary=f46d042f96421266d004d75c6da2
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2013 21:31:16 -0000

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 <pthatcher@google.com> 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
> <silviapfeiffer1@gmail.com> 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 <pthatcher@google.com>
> 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
> >> <silviapfeiffer1@gmail.com> wrote:
> >> > On Fri, Mar 8, 2013 at 5:51 AM, Mary Barnes <
> mary.ietf.barnes@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >> >> >
> >> >> > On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes
> >> >> > <mary.ietf.barnes@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
> >> >> >> <martin.thomson@gmail.com> 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
> >> > rtcweb@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/rtcweb
> >> >
> >
> >
>