Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 22 September 2011 20:02 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 6E05221F8C5B for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 13:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.38
X-Spam-Level:
X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 JHfTU9nvlhqR for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 13:02:04 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A5A7521F8BA0 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 13:02:03 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-b5-4e7b94d3ec29
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D0.92.20773.3D49B7E4; Thu, 22 Sep 2011 22:04:35 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 22 Sep 2011 22:04:34 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: 'Cullen Jennings' <fluffy@cisco.com>, Iñaki Baz Castillo <ibc@aliax.net>
Date: Thu, 22 Sep 2011 22:04:34 +0200
Thread-Topic: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism
Thread-Index: Acx5YP+JUCZH0D7BRlGuTIXFoeMPVAAATOvg
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FBC@ESESSCMS0356.eemea.ericsson.se>
References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <ED2DB00E-A64B-405F-96AC-2269258F6FFC@cisco.com> <4E799ECC.8030306@ericsson.com> <DB6B2796-9762-47CA-9A45-62476146DF04@cisco.com> <4E7B7272.7020204@alvestrand.no> <CALiegfkWv9wPj8N3FLT2UpksHARp7qdSXTJVTSEyBpL7pdujcg@mail.gmail.com> <18FFF339-E7EB-4EEB-BCD8-E6728A56A24A@cisco.com>
In-Reply-To: <18FFF339-E7EB-4EEB-BCD8-E6728A56A24A@cisco.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism
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: Thu, 22 Sep 2011 20:02:04 -0000

Hi Cullen, 

>>> Magnus' analysis worries me a bit, because it seems to assume 
>>> specific functionality in the gateway (tracking of state and ability 
>>> to generate SIP messages depending on state).
>>> It seems reasonably simple to build a gateway, but we quickly get to 
>>> the point where we have to write standards for the gateway function 
>>> .... which could lead us down rather deep ratholes.
>> 
>> Are we assuming that a media gateway will be required for RTP/media 
>> communication between a WebRTC client (web browser) and a SIP node?
>> If such decision is taken IMHO it's sad.
>
>My take is that most people want to make sure that a translator between SIP and web stuff would only need to look at signalling - it would not touch the media. I'm working on the asumption that is what any solution will look like. 
>So, no media GW. 

If so, what is your assumption then regarding ICE? That the SIP nodes will support ICE, or that the browser will be allowed to communicate with the SIP nodes without enabling ICE?

Regards,

Christer