Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 31 October 2011 12:58 UTC

Return-Path: <bernard_aboba@hotmail.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 1495621F8D80 for <rtcweb@ietfa.amsl.com>; Mon, 31 Oct 2011 05:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.451
X-Spam-Level:
X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoPnqKoVtKLy for <rtcweb@ietfa.amsl.com>; Mon, 31 Oct 2011 05:58:03 -0700 (PDT)
Received: from blu0-omc4-s9.blu0.hotmail.com (blu0-omc4-s9.blu0.hotmail.com [65.55.111.148]) by ietfa.amsl.com (Postfix) with ESMTP id 3379C21F8D7E for <rtcweb@ietf.org>; Mon, 31 Oct 2011 05:58:03 -0700 (PDT)
Received: from BLU152-W55 ([65.55.111.135]) by blu0-omc4-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 05:58:00 -0700
Message-ID: <BLU152-W553C788B9E9AAF618DA7D393D60@phx.gbl>
Content-Type: multipart/alternative; boundary="_aefff3c6-8ee8-481f-a17c-758361045978_"
X-Originating-IP: [24.17.217.162]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: fluffy@cisco.com, christer.holmberg@ericsson.com
Date: Mon, 31 Oct 2011 05:57:59 -0700
Importance: Normal
In-Reply-To: <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com>
References: <CALiegfkikmpi55ePUo=AQCQvorv4_6v2ByTCdL=V_=umcCEpUA@mail.gmail.com>, <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se>, <3BBCA56E-CA6E-4585-8EBB-ED6EDFED789F@cisco.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 31 Oct 2011 12:58:00.0177 (UTC) FILETIME=[B7ECBE10:01CC97CC]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)
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: Mon, 31 Oct 2011 12:58:04 -0000

Cullen said:


> Hmm we should talk about this - I have a hard time seeing how that is going to work. I was working on the assumption that  PeerConnection 
>could deal with more than one offer/answer pair at a time. Given the current WebRTC API and something like ROAP - it seems like that should just work. 


[BA] We have an issue with the API spec if that it is possible for people to come to very different conclusions about whether this and other things
"should just work".   BTW, this was *not* my reading of the spec -- it seems to me that there are inherent assumptions about the state machines,
ICE and other aspects that would restrict a PeerConnection to one offer/answer pair at a time.