Re: [rtcweb] Agenda requests for Atlanta meeting

Cullen Jennings <fluffy@iii.ca> Tue, 09 October 2012 02:30 UTC

Return-Path: <fluffy@iii.ca>
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 20E911F0C54 for <rtcweb@ietfa.amsl.com>; Mon, 8 Oct 2012 19:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 X43zr83cY8pi for <rtcweb@ietfa.amsl.com>; Mon, 8 Oct 2012 19:30:11 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 58DEF1F0423 for <rtcweb@ietf.org>; Mon, 8 Oct 2012 19:30:11 -0700 (PDT)
Received: from [10.21.86.152] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C3A1022E259; Mon, 8 Oct 2012 22:30:04 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CAD5OKxvLQYXwGD8TtgoBus_fpvek96JYpx80zgFT1EuWz7AoEw@mail.gmail.com>
Date: Mon, 8 Oct 2012 19:30:44 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <86A92683-F9C3-45AB-B985-573811436850@iii.ca>
References: <506B0367.4000103@ericsson.com> <C5E08FE080ACFD4DAE31E4BDBF944EB111867718@xmb-aln-x02.cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB11187F8FB@xmb-aln-x02.cisco.com> <CAD5OKxtDnXafE=3R-7X9vL1TaYMauYL56JFfyJoTztDMbe4DqQ@mail.gmail.com> <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> <CAD5OKxsEmgUJXUYaFRnkDZhoZdzZaD4rCvoUFPNVdd6L1FWDjQ@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB11187FB09@xmb-aln-x02.cisco.com> <CAD5OKxvxC8cLuwBbVMM+dmb8eZ=1=HYu6kprhi9QkLdRLz_4jw@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB11187FC44@xmb-aln-x02.cisco.com> <CAD5OKxsF4bSvi5SQ9OU1mcqGYeEHUMiYsLaRo_sKoMs8-_7m0A@mail.gmail.com> <98BB750F-F263-44BB-9CC3-1F0816C11061@iii.ca> <CAD5OKxvLQYXwGD8TtgoBus_fpvek96JYpx80zgFT1EuWz7AoEw@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: Apple Mail (2.1499)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda requests for Atlanta meeting
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:30:12 -0000

On Oct 8, 2012, at 18:56 , Roman Shpount <roman@telurix.com> wrote:

> On Mon, Oct 8, 2012 at 9:41 PM, Cullen Jennings <fluffy@iii.ca> wrote:
> 
> On Oct 8, 2012, at 18:31 , Roman Shpount <roman@telurix.com> wrote:
> 
> > On Mon, Oct 8, 2012 at 9:26 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
> >
> > Well, what's the end user experience you're trying to achieve  - lets say we are talking about audio. Do you want to play the first one or the last one? If you want to bridge them into a party line, this is probably not how you want the SIP side to happen.
> >
> >
> > This is still serial forking. Imagine the following scenario: You are calling a phone number, you dial first provider who starts playing a dial tone then uses an UPDATE to connect you to a media server to play an announcement after which your call goes to voice mail (another dialog and another SDP). This is all fairly legal and not unusual for SIP scenarios. Nothing to do with party lines.
> 
> Ok, serial forking with early media seems like it should work. Seems like the browser would make the offer, that gateway turned into SIP invite that then went to sequential forking proxy that send sent the invite to UA A. UA A returns a 180 that gets mapped to PRANSWER, the proxy then forks to UA B that sends a 200 on a different dialog that gets mapped to answer.
> 
>  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.