IETF Logo Mail Archive

Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

Christer Holmberg <christer.holmberg@ericsson.com> Sat, 29 October 2011 21:48 UTC

Return-Path: <christer.holmberg@ericsson.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 AAAE821F862F for <rtcweb@ietfa.amsl.com>; Sat, 29 Oct 2011 14:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.212
X-Spam-Level:
X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Y8BvNnFZ65lG for <rtcweb@ietfa.amsl.com>; Sat, 29 Oct 2011 14:48:44 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D93D521F85FF for <rtcweb@ietf.org>; Sat, 29 Oct 2011 14:48:43 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-8e-4eac74ba6887
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 28.89.13753.AB47CAE4; Sat, 29 Oct 2011 23:48:42 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.197]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 29 Oct 2011 23:48:42 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, Randell Jesup <randell-ietf@jesup.org>
Date: Sat, 29 Oct 2011 23:44:26 +0200
Thread-Topic: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]
Thread-Index: AQHMlb+MtYdQSlKDHEijV6ncguiECZWT3FwC
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852234CFCA00@ESESSCMS0356.eemea.ericsson.se>
References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <CALiegfnVaZjh1K+brd180Z9Ufheau3v6OJe6Ejv8P7wzw6ROQw@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org>, <817D03B4-A50D-4047-A638-4BFA231543E2@acmepacket.com>
In-Reply-To: <817D03B4-A50D-4047-A638-4BFA231543E2@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]
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: Sat, 29 Oct 2011 21:48:44 -0000

Hi,

> Yes, but in theory we don't need to support ROAP forking to let you do that, because you don't need to do it that way.  For example you
> can write the JS to send a "session request" message without any ROAP/SDP, and as each "session response" comes back from each team 
> member with a ROAP OFFER, the local JS creates a new PeerConnection and sends back to each team member a ROAP ANSWER from you. 
> So basically mimicking the offerless-INVITE model of SIP.

That would cause issues with SIP interworking. I hope we can agree on the fact that many (most?) SIP environments and use-cases rely on the SDP offer being sent in the INVITE. The gateway would end up having to map SIP answers into ROAP offers, and vice verse, which could become very messy.

And, when the gateway receveis on offerless ROAD offer, if it needs to map it into an INVITE with an SDP offer, what information would it include in the SDP offer?

Regards.

Christer

v2.23.0 | Report a Bug | By Email