Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

Christer Holmberg <> Thu, 04 October 2012 18:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0A9521F8661 for <>; Thu, 4 Oct 2012 11:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.808
X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VPZilUFeHBEi for <>; Thu, 4 Oct 2012 11:21:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CA58C11E80E1 for <>; Thu, 4 Oct 2012 11:21:24 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-b4-506dd3a339aa
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B4.0A.25676.3A3DD605; Thu, 4 Oct 2012 20:21:23 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Thu, 4 Oct 2012 20:21:23 +0200
From: Christer Holmberg <>
To: Martin Thomson <>, Harald Alvestrand <>
Date: Thu, 4 Oct 2012 20:21:22 +0200
Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules?
Thread-Index: Ac2iWjXSYW+MEZhGQze7n9Bl7WSeEAAAGpH2
Message-ID: <>
References: <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre7iy7kBBnMPmVsc6+tis7h25h+j xdp/7ewOzB5XJlxh9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mrb8n8Nc8FSwYsabkAbG ZXxdjJwcEgImEnfO/WWFsMUkLtxbz9bFyMUhJHCKUWLRxn5WCGc2o8SdnzOBMhwcbAIWEt3/ tEEaRAQiJY4cOcsOYjMLqEvcWXwOzGYRUJFof9HLCGILCxhLdH4+xgRRbyKxZscaFgjbSGLV jIlgNbwC4RKrjm+AWjybWWLRjg6wIk6BQImjy56ADWUEuu77qTVMEMvEJW49mc8EcbWAxJI9 55khbFGJl4//sULUi0rcaV/PCFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUWwWkrGzkLTM QtIyC0nLAkaWVYzCuYmZOenlRnqpRZnJxcX5eXrFqZsYgfF0cMtv1R2Md86JHGKU5mBREue1 3rrHX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPj/JLOPz+3yZ9+s91Fg60mzWmnmYKowLwP byyf8XzeYcWSOoND2ZTJLiiPecfNvuqrTyO3HP4op3VStHTRZB4j4xXTM43PXrY9wpnMIZMm HpdTL11Z43yt94JxztK38pr5qjNyd6fOP7Pr28vpX1WcA/Z1n9vWVvbgYN/0hnCppm3h85Ot 2hKUWIozEg21mIuKEwH7+jnRdQIAAA==
Cc: "" <>
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?
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: Thu, 04 Oct 2012 18:21:28 -0000


>> For the Web use case, I think PRANSWER is an unnecessary distraction; if
>> we're writing both initiator and responder, multiple O/A rounds, or use of
>> multiple PeerConnections, is a much cleaner solution for the use cases I can
>> wrap my head around.
> I'd remove that qualifier.  We currently have a draft that describes
> both cloning AND PRANSWER, both of which are more cleanly addressed by
> either multiple O/A rounds or multiple independent sessions.
>The ability to describe a session that includes receipt capabilities
>that are a superset of send capabilities.  SDP O/A doesn't really
>provide a way for me to describe this because the default assumption
>is that items not appearing in the answer are no longer needed.
>With something like bundle involved, we could split m= lines into
>sendonly and recvonly portions to allow for this case to be provided.

I don't think the reason for PRANSWER comes from SDP O/A as such. It's more about supporting serial forking.

>The ability to use the same transport primitives to interact with
>multiple peers.  Ostensibly, this is to prepare for a session, with
>only one continuing to completion, mainly to reduce clipping.
>By adding candidates from all serial offenders to the same answer, you
>can get ICE setup, though I doubt that DTLS handshakes will be able to
>complete unless we permit multiple a=fingerprint lines and a few other
>things.  I'm still disinclined to support this feature.  Let the
>forkers have clipping.

If you want to support parallel forking, you need to be able to simultanously perform ICE etc with all remote peers.

>Both of these complicate the API significantly.  I'd rather see the
>complexity pushed to the applications that need this complexity.

I want to be able to support forking. Exactly HOW it's done can be discussed.

Also, I can live without support of parallel forking, and I don't really care if serial forking support is provided using cloning or being able to update the remote descriptor (using PRANSWER, or something else).

>That is, unless you are willing to consider a better API that makes
>these issues SEP.

You have one in mind? ;)