[rtcweb] PRANSWER is unusable for serial forking

Roman Shpount <roman@telurix.com> Tue, 09 October 2012 02:46 UTC

Return-Path: <roman@telurix.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 0592011E809B for <rtcweb@ietfa.amsl.com>; Mon, 8 Oct 2012 19:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT3L8DzboD69 for <rtcweb@ietfa.amsl.com>; Mon, 8 Oct 2012 19:46:29 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA6B1F0423 for <rtcweb@ietf.org>; Mon, 8 Oct 2012 19:46:28 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id fl11so6219282vcb.31 for <rtcweb@ietf.org>; Mon, 08 Oct 2012 19:46:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=zWx1Yic89ZQpk++XLhc6T4Y8PUJtvl9ZBWl1yxBO/sI=; b=KXmhrEOLockZu3/YbLeq0cStI4Dzq5lfVXYobunStywgUX+2Bglup5Rc/p08J3a7/G b+f9KYIleYOWwqXaDUDNAsNAqbFcwuK6WyVEfqnfoJSkJgE30glhgkUuWsqVPbppBEvD UifeGFO9rghNRzgzoQ5zDh+uJNcCa14QWYOo4NfNlYJfskT6i3JFYTDcKMCRqPYpeUgE 3Z/WL+EA/caAGIsZOHUA1y1JBjpoJemOqdu/AfTDDxQ/HZrTxe9B6MkH9+bJN+ss5K9v JgYL23m873SBWl/20QWVSlQKi+As1Dhn7nRCfwzmXF/kunuvOIwhWkzMkaM2s5AHvJQb 4Wjg==
Received: by 10.58.144.232 with SMTP id sp8mr11221706veb.56.1349750785762; Mon, 08 Oct 2012 19:46:25 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPS id v4sm2619038vds.3.2012.10.08.19.46.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 19:46:25 -0700 (PDT)
Received: by mail-vc0-f172.google.com with SMTP id fl11so6219229vcb.31 for <rtcweb@ietf.org>; Mon, 08 Oct 2012 19:46:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.231.8 with SMTP id tc8mr11248180vec.52.1349750783673; Mon, 08 Oct 2012 19:46:23 -0700 (PDT)
Received: by 10.58.240.84 with HTTP; Mon, 8 Oct 2012 19:46:23 -0700 (PDT)
Date: Mon, 8 Oct 2012 22:46:23 -0400
Message-ID: <CAD5OKxuOVgcKY_PBLXHeT_cyqJU9sExDWmP1M5u3-87cMQWtVA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Cullen Jennings <fluffy@iii.ca>
Content-Type: multipart/alternative; boundary=047d7bf0d174ff06d204cb97577c
X-Gm-Message-State: ALoCoQmZ4SCoYSRpJWZ2aW7XTq/rCGIA0oUAetonmmUO8otZ5oSH7aKL9cXhjkJTpeiT3Gj7kDHe
Cc: rtcweb@ietf.org
Subject: [rtcweb] PRANSWER is unusable for serial forking
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: Tue, 09 Oct 2012 02:46:30 -0000

Changing subject

On Mon, Oct 8, 2012 at 10:30 PM, Cullen Jennings <fluffy@iii.ca> wrote:

> >  The only issue is the there is currently no way to map an UPDATE
> received in the early dialog to WebRTC API calls. I am probably OK with it
> not being handled until the cloning is implemented, but this shows that
> PRANSWER is not very useful even for the serial forking.
> >
>
> How do you think this work in a SIP only system? Lets say A sends the
> invite with offer to proxy that forks to B. Then B does 180Rel followed by
> an update. Then the proxy forks to C on a new dialog. Do you think C can
> send send early media to A and A is actually going to play it? And what if
> B use still sending media - it that case A will be getting media from B and
> C at the same time. Do you have devices that do that?  Most people just
> seem to make voicemail work fine without needing to introduce this type of
> complexity. If you know what you want A to do in this case, I think we can
> figure out how to make that happen - there's been a lot of discussion about
> what a SIP device receiving early media from two places should do and there
> was never any really great answer other than don't do that.
>
> The meta issue here is thought this is serial forking at the signalling
> level in SIP, it is actually parallel forking from a SDP / media  point of
> view.
>
> The case that started this all was use UPDATE in awaited RFC says is not
> allowed. I'm not arguing there are not cases where clone would be useful,
> but I do think all the voicemail systems I am familiar with would work fine
> with the the simple PRANSWER.
>
>
This actually works fairly well in the current systems. The fact that
UPDATE is used does not mean there are multiple media streams flowing at
any given time. And, I am familiar with a couple of systems that do exactly
what I have described. Typically some sort of announcement or
color-ring-back system followed by a voice mail. I think the problem is
that this group picked one interop scenario and added something to support
it while arbitrarily deciding that other scenarios should not be supported.
SIP does not have serial forking. Offer/Answer does not describe something
like this. We either need to define it and make it something that describes
some set of existing scenarios or add support for something that is defined.
_____________
Roman Shpount