Re: [rtcweb] Unified plan IPR

cowwoc <> Tue, 23 July 2013 21:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65C6411E8289 for <>; Tue, 23 Jul 2013 14:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2i7Iuq0gePzs for <>; Tue, 23 Jul 2013 14:58:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 77AAE11E8271 for <>; Tue, 23 Jul 2013 14:58:27 -0700 (PDT)
Received: by with SMTP id cl20so1928611qab.16 for <>; Tue, 23 Jul 2013 14:58:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=xF3wxS6v2166/sIx5iwb587v/pbLiY/uih3lIF29bLc=; b=YYWm3pFasZ8JXeRKeNA5PfhWdpSpHuYQOqXL5g+xyBLn5VK3kh5vAM+dyeYFsSWl6P uo87gbhBBBVxQ4QrttBnC+lKwWXaowFGhINDyT0rlab1wBHoNMosgmrsUyNVzlo6lxPY kUZh58maqEkOVW1kMbLH8CkndnWoamNVqfxToXifSKRL0SQLZQSsvp8V12VluQ0GgiAE 0ZbN8HMAwaMqY8NMU43m5R8XQEJf0IyDExDXA4gvotDP84ptpiMtUYO2eZAAhltypPj8 b9xrDQZgv6+UVuwOPbCz4VobJiHaZdRBy4a6Nl4QliJPiauYcuwgwQhdaNIivSZ3iKZA 1SLA==
X-Received: by with SMTP id q11mr42225170qak.35.1374616706665; Tue, 23 Jul 2013 14:58:26 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id n16sm310329qae.8.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 14:58:25 -0700 (PDT)
Message-ID: <>
Date: Tue, 23 Jul 2013 17:58:03 -0400
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------060605090502050100050201"
X-Gm-Message-State: ALoCoQmZd1Wfj74X38AOPata+OwBcHExmQmt6NDAFzm39mLLbXjBiF2MgPkxGdJXYXv29M/ZAh9T
Cc: "" <>
Subject: Re: [rtcweb] Unified plan IPR
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jul 2013 21:58:32 -0000

On 23/07/2013 12:51 PM, Adam Roach wrote:
> On 7/23/13 11:22, Roman Shpount wrote:
>> The situation would be a bit clearer if patent holders were to 
>> provide the licensing policy regarding this IPR release. Given that 
>> Ericsson is actively involved in this working group, I think it would 
>> be reasonable to ask them for this.
> If process has been properly followed, the IPR holder has already been 
> notified by the IETF executive director. See 
> (section 1 paragraph 1)
> I doubt agitating for action on these mailing lists is likely to 
> produce useful results.
> /a

Hi Adam,

     I'm a bit concerned about the optics of what just happened.

  * The Working Group has been pushing for the use of SDP since 2011
  * The first post related to the use of SDP in WebRTC came from
    Christer Holmberg of Ericsson on September 14th, 2011.
  * One of the Chairs of the Working Group and one of the Specification
    editors are from Ericsson.
  * There has been a substantial push against the use of SDP by some
    mailing list participants, but this was rejected by the Working Group.
  * Suddenly we find out that Ericsson has filed two patents related to
    the use of SDP in WebRTC and these were filed *after* Ericsson
    actively pushed for the use of SDP.

     Isn't there a conflict of interest here?

     As a Web Developer who doesn't want/need SDP to begin with, I am 
finding this a bitter pill to swallow. I have no problem with other 
people using SDP (all the power to them) but, with this IPR discovery, 
forcing their preference on me will have real-world consequences (no 
less than had we mandated the use H264 in WebRTC).

 1. Do the patents imply that Web Developers will have to pay patents
    when deploying application on top of the Browser or Native APIs?
 2. Is there a way to retrofit the API so those of us who do not
    want/need to use SDP are not forced to license this IPR? For
    example, the specification states that the initial offer/answer
    mechanism is out of scope. Could we do the same for SDP?

Thank you,