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

Cullen Jennings <> Thu, 22 September 2011 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 656AA1F0C6D for <>; Thu, 22 Sep 2011 13:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.469
X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R4N2iS7RSxZa for <>; Thu, 22 Sep 2011 13:35:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 098191F0C63 for <>; Thu, 22 Sep 2011 13:35:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2078; q=dns/txt; s=iport; t=1316723877; x=1317933477; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4rIYbjI7NFftNctr/LzHwQjCOOEmeq4LhgvnUkRuZok=; b=erWl43iiz1Ie2n7HTEysgWIStEoXcJOgtTrcaynNbP57BA+d1yS7qkav bMTDnGljbUrR7bERjffRJACteOvG+5EBWW7qOLyloFhxbN3a8C1jWmck0 MdpTSGOlkmCUk/boQLu+BuVGuagC/YTs6WQF99db0ogXscNloHIEJEHE+ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAF6ce06rRDoI/2dsb2JhbABCqAJ4gVMBAQEBAgESASc/EAtGVwYuB4dWlxoBniaGHWAEh3GLX4UfjC8
X-IronPort-AV: E=Sophos;i="4.68,425,1312156800"; d="scan'208";a="3742677"
Received: from ([]) by with ESMTP; 22 Sep 2011 20:37:57 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p8MKbuV8031494; Thu, 22 Sep 2011 20:37:56 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <>
In-Reply-To: <>
Date: Thu, 22 Sep 2011 14:37:56 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Christer Holmberg <>
X-Mailer: Apple Mail (2.1084)
Cc: "" <>
Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Sep 2011 20:35:25 -0000

On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote:

> 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?

I see no way of solving the security problems without having ICE or something more or less like it. Therefore, I'm working on the assumption that it will only work if the SIP side supports ICE, or is front ended by a SBC with media GW that does ICE. In the short term, there will be some devices that don't do ICE but SIP devices are increasingly having ICE added. Particularly SIP devices that are internet facing because the need for NAT traversal. 

I find requiring ICE to be a very unfortunate assumption to have to make - obviously it reduces the number of legacy voip devices WebRTC devices can talk to without an SBC but I don't see any way around this limitation. Allowing web browsers inside the firewall to send packets to an arbitrary address that is inside the firewall with no validation that address speaks RTP is not acceptable.