Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

Roman Shpount <> Thu, 10 May 2012 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2202421F8649 for <>; Thu, 10 May 2012 12:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.894
X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Dbp61wQ4L-6b for <>; Thu, 10 May 2012 12:51:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 39D2721F8644 for <>; Thu, 10 May 2012 12:51:32 -0700 (PDT)
Received: by dacx6 with SMTP id x6so2250267dac.31 for <>; Thu, 10 May 2012 12:51:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=PyBNUiVWk3Cnkzn5ptjQ8JZxGhPYqfV6b7YRXHO711c=; b=IVAhAmEa133lb087jwlMlTf7IOb89b2KJJm680y3cqF7yDI1KMWGZMIKSnppImrngy XgpIWJHcH6fBTVBTGoJVcykFCVFCwTFSnwzYCVtjiV/didQFuDtT5a6t5UJdi51w+kdq Sbb1QXh2H4XWSPwnNJWbjpMuxG2RA/MaafNCD03/kh4r01KRWC8ezl9gIArSJXBs9QO0 lZx3fL//eSkKcLXC6lc1nrNfJ7HGx5YXVSMjkzQfqqghnbG/kFcx5Rd9NR5837mqhcxR qLNIDjsCO7NQTOk+38QNQoNhdwRMau2EGxBD/NBAXN/OOqOwK1hxw/NBpfRtZTey/Hq9 rVqQ==
Received: by with SMTP id kp2mr57401pbc.103.1336679491908; Thu, 10 May 2012 12:51:31 -0700 (PDT)
Received: from ( []) by with ESMTPS id ud10sm10390649pbc.25.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 12:51:30 -0700 (PDT)
Received: by dacx6 with SMTP id x6so2250227dac.31 for <>; Thu, 10 May 2012 12:51:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id he10mr3612079pbc.69.1336679489369; Thu, 10 May 2012 12:51:29 -0700 (PDT)
Received: by with HTTP; Thu, 10 May 2012 12:51:29 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 10 May 2012 15:51:29 -0400
Message-ID: <>
From: Roman Shpount <>
To: Cullen Jennings <>
Content-Type: multipart/alternative; boundary="e89a8ff24e1124777404bfb3f206"
X-Gm-Message-State: ALoCoQlISgi9bdT6YEMDWYwE1C3oNAJ/J9dJN2VYABTy9KV6FQaFkbqu6Ooqg5iYUywMCTsl2+q/
Cc: Randell Jesup <>, "" <>
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
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, 10 May 2012 19:51:33 -0000

On Thu, May 10, 2012 at 3:06 PM, Cullen Jennings <> wrote:

> Uh, I don't think we are ready to design anything yet - I am still 100%
> confused on what the use case we are trying to solve is. Is it forking on
> at the browser, in intermediate node, in SIP, parallel, sequential or what?
> I want to see the end user use cases we need to deal with. The example
> Randell gave seems reasonable but seem like it would best be handled with
> just multiple independent PeerConnection. The combination of requiring ICE
> and SIP parallel forking is very complicated - particularly without
> Reliable provisions responses and all the complexity that ensues.
> So before we go down this path, lets get clearer on what we are trying to
> accomplish.
One use case is interop with SIP with parallel forking, reliable
provisioning responses, UPDATE, and ICE. The big question regarding this
use case is availability of anything that supports parallel forking,
reliable provisioning and UPDATE. I actually think ICE makes implementation
of this use case easier, not harder.

The real end user use case is any type of service where calling destination
is a small group of people. This allows to initiate a single offer and send
it to all the members of the group. In most cases only one person will
reply, but, in a smaller set of cases, several people from the group will
answer. In the later case, you need a mechanism to clone the original peer
connection (or to create additional peer connections based on the original
offer) and deal with additional answers independently.

This is a very common use case for any type of service where people use
multiple devices. For instance if we add voice/video calling to a web mail
program, I can be logged in from multiple devices. It can also be a shared
account (like where several different people are logged
in to the same account. When someone places a call to a shared account,
several people can answer at the same time.

I know this can be addressed by sending a separate message  and reversing
the call setup direction (each accepting party creates an offer and sends
it back), but this causes another set of issues related to slow call setup
and media clipping.
Roman Shpount