Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching

Iñaki Baz Castillo <ibc@aliax.net> Mon, 03 October 2011 12:26 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 86FCF21F8B0A for <rtcweb@ietfa.amsl.com>; Mon, 3 Oct 2011 05:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.337
X-Spam-Level:
X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, 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 fAQAyd20oiQi for <rtcweb@ietfa.amsl.com>; Mon, 3 Oct 2011 05:26: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 07F9B21F88B7 for <rtcweb@ietf.org>; Mon, 3 Oct 2011 05:26:22 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so4232505vcb.31 for <rtcweb@ietf.org>; Mon, 03 Oct 2011 05:29:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.184.67 with SMTP id cj3mr3239599vcb.76.1317644964958; Mon, 03 Oct 2011 05:29:24 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Mon, 3 Oct 2011 05:29:24 -0700 (PDT)
In-Reply-To: <77D2298D-49EF-4F11-A50C-F1EE17082ECD@edvina.net>
References: <E44893DD4E290745BB608EB23FDDB7620D3782@008-AM1MPN1-043.mgdnok.nokia.com> <77D2298D-49EF-4F11-A50C-F1EE17082ECD@edvina.net>
Date: Mon, 03 Oct 2011 14:29:24 +0200
Message-ID: <CALiegfnbU4YhuNJ4AatR+0s8JJxp9uQR-x7pk1GmFwDAnnzQkw@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: "Olle E. Johansson" <oej@edvina.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching
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, 03 Oct 2011 12:26:23 -0000

2011/10/3 Olle E. Johansson <oej@edvina.net>:
> THe SIP outbound extension has handling of IP address change during a registration/connection. But that doesn't imply IP address change during a call.

When a SIP client implementing the outbound extension (RFC 5626)
detects that the TCP (or TLS or WebSocket) connection is
terminated/down, it should re-register and should send a re-INVITE for
established dialogs telling the peer about its new location and SDP
address. In fact, the using RFC 5626 the client does not need to know
its exact local IP:port, as the edge proxy would route back incoming
in-dialog request using the new client connection.


> Software like Asterisk has added protection on the RTP ports so after initial packets (handling symmetric RTP) Asterisk will not accept packets from an unknown IP.

It should allow a change in the source IP:port of the RTP packets in
case a re-INVITE has been sent by the peer.


> I would assume that if we had ICE support, ICE could re-initialize the session and the server could open new connections.

I expect this to be the same: the client would send a re-INVITE after
detecting local address change and Asterisk should accept it and
update the session information.



Regards.


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