Re: [rtcweb] How to get a diff between the remote SDP in an established session and a new received SDP offer

Martin Thomson <martin.thomson@gmail.com> Fri, 06 July 2012 16:15 UTC

Return-Path: <martin.thomson@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 A180721F86DB for <rtcweb@ietfa.amsl.com>; Fri, 6 Jul 2012 09:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level:
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 u8fZn7v8-696 for <rtcweb@ietfa.amsl.com>; Fri, 6 Jul 2012 09:15:55 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE3521F87C4 for <rtcweb@ietf.org>; Fri, 6 Jul 2012 09:15:54 -0700 (PDT)
Received: by bkty7 with SMTP id y7so1440464bkt.31 for <rtcweb@ietf.org>; Fri, 06 Jul 2012 09:16:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mTCU1v1Pwk05GBY4FEXV/6RK8azMshJKRsntX3p0hKQ=; b=zLaLdmBrcQlolDD0Eyl1FJs9StZbS3W3ZUjSvbDx1KN5vqZQ/3crv3IPMsYFsNA8bz 2F3gaB18aq0qj38zCMLBFGclimWTJGLahoxcf4mB+xOqjCgzQKvpIOUl+/tj9OIPbBUd Vbg2ef6+RKywlpkNnr6V8v1AOrLJpwhGmYqOd4gTglXF4XoETpwcX/3Nnzku9hmgmXjY qh9zHE4j4X072J5aqKqXm8djJH2aLl4v/BV+e1NfDHDPpc68e8DzUI+OFlySu8sh7dQ7 N8KAhIphzTN3oHQxYz/ayS38fO8f4gfkJPVPSQANSx5UJ/Cp2cS+uosTAxXcX5juoHBt 8D9A==
MIME-Version: 1.0
Received: by 10.204.155.69 with SMTP id r5mr5072888bkw.49.1341591370381; Fri, 06 Jul 2012 09:16:10 -0700 (PDT)
Received: by 10.204.66.4 with HTTP; Fri, 6 Jul 2012 09:16:10 -0700 (PDT)
In-Reply-To: <CALiegf=KbUw9c81RWdTAiFGyd2ntwdaJ4BYsoGUduwE=JSbLLg@mail.gmail.com>
References: <CALiegfkKv8YBW1Lo0+bT0rBtheTsNde0+PTej+xZZmo7xPaYpA@mail.gmail.com> <CALiegf=KbUw9c81RWdTAiFGyd2ntwdaJ4BYsoGUduwE=JSbLLg@mail.gmail.com>
Date: Fri, 06 Jul 2012 09:16:10 -0700
Message-ID: <CABkgnnUZWbLP1dG1NHqn_puY0NVQuDnNkGNz1Mo9MYXf4Y_d_Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] How to get a diff between the remote SDP in an established session and a new received SDP offer
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: Fri, 06 Jul 2012 16:15:56 -0000

On 6 July 2012 00:33, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> I hope that raw parsing of the received SDP is not needed for achieving this :)

I'm surprised that you think that.

I believe that the subject is one of the open issues, though I believe
that the current discussion was heading toward the conclusion that
calling set<X>Description() on a PeerConnection was the blessed method
for determining what streams are present in an offer or answer.

Therefore, the process is something like...

# Take existing session, look at the attached streams (and their tracks).
# Take new offer, create new PeerConnection, attach the same local
streams, call pc.setRemoteDescription(OFFER, sdpOffer), examine the
resulting attached streams (and their tracks).
# Discard the new PeerConnection.

Of course, this is highly likely to fail because the resources
necessary to create and configure the second PeerConnection are likely
taken by the first.  So your best bet is to scrounge through the SDP.
But SDP is awesome, so it's OK.

--Martin