IETF Logo Mail Archive

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

Iñaki Baz Castillo <ibc@aliax.net> Sun, 30 October 2011 19:12 UTC

Return-Path: <ibc@aliax.net>
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 7402521F8AD9 for <rtcweb@ietfa.amsl.com>; Sun, 30 Oct 2011 12:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.645
X-Spam-Level:
X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 h8zk9BXhaOEZ for <rtcweb@ietfa.amsl.com>; Sun, 30 Oct 2011 12:12:23 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB16D21F8AD3 for <rtcweb@ietf.org>; Sun, 30 Oct 2011 12:12:22 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so5256359vcb.31 for <rtcweb@ietf.org>; Sun, 30 Oct 2011 12:12:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.150.212 with SMTP id z20mr1911834vcv.58.1320001942347; Sun, 30 Oct 2011 12:12:22 -0700 (PDT)
Received: by 10.220.184.6 with HTTP; Sun, 30 Oct 2011 12:12:22 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se>
References: <CALiegfkikmpi55ePUo=AQCQvorv4_6v2ByTCdL=V_=umcCEpUA@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852235717390@ESESSCMS0356.eemea.ericsson.se>
Date: Sun, 30 Oct 2011 20:12:22 +0100
Message-ID: <CALiegf=t=9YSbZ1fmCQs0BrV79TPAkXB5XEsONRA4KP_um4DtA@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <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: Sun, 30 Oct 2011 19:12:23 -0000

2011/10/30 Christer Holmberg <christer.holmberg@ericsson.com>:
> I don't like the idea of having to send UPDATE/re-INVITE for every new early dialog.

Hi Christer, it was just a suggestion, I'm not traying to mandating or
standarizing nothing :)


> In addition, I am not even sure it would work with ICE. Remember that ICE allows the UAS to send an "answer" unreliably (the unreliabe 18x is re-transmitted a few times), but since it's not a real answer, the UAC is not allowed to send an UDPATE.

I don't agree. If the UAC receives a 180 it means that the 180 has
been received (regardless it was unreliable), so UPDATE is possible.


> In my opinion a better solution is to create a new PeerConnection for every new early dialog, which uses the *same* address/candidate parameters as the "parent" PeerConnection. In such case there is no need to send an UPDATE.

Sure! but my suggestion was based on the assumption that WebRTC won't
allow reusing the same local address/candidates in two different
PeerConnection's.

Regards.




-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email