IETF Logo Mail Archive

Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09

Iñaki Baz Castillo <ibc@aliax.net> Mon, 17 June 2013 17:50 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACA621F9D43 for <sipcore@ietfa.amsl.com>; Mon, 17 Jun 2013 10:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.732
X-Spam-Level:
X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 UXHr0GAjLKwG for <sipcore@ietfa.amsl.com>; Mon, 17 Jun 2013 10:50:18 -0700 (PDT)
Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D0E5421F9D3D for <sipcore@ietf.org>; Mon, 17 Jun 2013 10:50:17 -0700 (PDT)
Received: by mail-qc0-f173.google.com with SMTP id l10so1772300qcy.32 for <sipcore@ietf.org>; Mon, 17 Jun 2013 10:50:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ZgiQtiPa1FxU65PVbD5LVDVeEIkcNurXp6EU9gLvG6Q=; b=oomu1oS1/CMmcx+mPKTyB+jyxyuqKVfw2+pz3i/um9AMYtWdLYAcvr+fds95SRzwC2 lZf9q9rXPcXvP3rhI2N03vl32TQCclKmusfMjoTl7ha7Hwc/rsm+FPaDYMLCoz6d1uJ7 qDHLfxpy4PJHF1Gj6c7Z+BC5p4rYG1MqO75HyCsgVj7PAi97MjJtkraJx/mVgdGi+ivG z/DV4qp92/hwpsCmx/nXHmivKAHH4BSQSfio/3gldIwdKnVOdeTKvvApSB+AE24dIEdT S15lLZPCm5vSlYatWt0jb6NSF8hNxicUndjO0+LNgoqGx9QOmu2xiSIRby0OauJat7my zI8Q==
X-Received: by 10.229.168.132 with SMTP id u4mr6677502qcy.73.1371491417105; Mon, 17 Jun 2013 10:50:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.67.65 with HTTP; Mon, 17 Jun 2013 10:49:57 -0700 (PDT)
In-Reply-To: <005801ce6b81$c6669d50$5333d7f0$@co.in>
References: <CALiegfmtohM8Nnf34o2EqMr-jV-LaQBP7mOB5qq+7OcQO9FkSA@mail.gmail.com> <003f01ce6aaf$aabda760$0038f620$@co.in> <CALiegf=U9fNPcL83TbWPQirNczZ-faHmG1R+AiPVuBLa=pfe6A@mail.gmail.com> <005801ce6b81$c6669d50$5333d7f0$@co.in>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 17 Jun 2013 19:49:57 +0200
Message-ID: <CALiegf=B48qzkt2VAVsg3n+86KgPS-xb=48+Mf3uLY9sibGXgA@mail.gmail.com>
To: Parthasarathi R <partha@parthasarathi.co.in>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkpvDJT8kmQw0w9VDHsv8MvkbnXP77i0FkcJoC9Q3c5yBbzvb+jJ/yrB8+knhRyaPXc1Qlu
Cc: "SIPCORE (Session Initiation Protocol Core) WG" <sipcore@ietf.org>
Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2013 17:50:18 -0000

2013/6/17 Parthasarathi R <partha@parthasarathi.co.in>:
> As you mentioned, "record-route" is the right solution and not documented in the draft as of now. My comment is to explicitly add the statement for clarity.

The draft describes a SIP transport, not a network topology.

For clients behind NAT, RFC 5626 (Outbound) already describes a
mechanism and requirements for clients and proxies to properly work.
RFC 5626 can perfectly be applied to scenarios in which SIP-WebSocket
is present. So no need to duplicate all the information provided by
RFC 5626 in this draft.

Anyhow, the Appendix "Implementation Guidelines" already suggests
using Record-Route within the "SIP WebSocket Server Considerations"
subsection:

   The SIP Outbound extension [RFC5626] seems an appropriate solution
   for this scenario.  Therefore these SIP WebSocket Clients and the SIP
   registrar implement both the Outbound and Path [RFC3327] extensions,
   and the SIP proxy acts as an Outbound Edge Proxy (as defined in
   [RFC5626] section 3.4).

And of course RFC 5626 already states that a Outbound Edge Proxy must
do record-routing. I hope this draft won't become a "general tutorial
for SIP and NAT".


Regards.

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

v2.23.0 | Report a Bug | By Email