IETF Logo Mail Archive

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

Iñaki Baz Castillo <ibc@aliax.net> Sun, 16 June 2013 21:15 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 0D24B21F9B8C for <sipcore@ietfa.amsl.com>; Sun, 16 Jun 2013 14:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 alLm0n4VFHW6 for <sipcore@ietfa.amsl.com>; Sun, 16 Jun 2013 14:15:19 -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 823CE21F9B76 for <sipcore@ietf.org>; Sun, 16 Jun 2013 14:15:18 -0700 (PDT)
Received: by mail-qc0-f173.google.com with SMTP id l10so1234032qcy.18 for <sipcore@ietf.org>; Sun, 16 Jun 2013 14:15:18 -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=Q5UvhPj+FjPmfOn9/6BdqwDHskMrlapPvapxgSjRmXA=; b=owemiexOC6SWMM+2jKsudcVBovn9NMg7QnrqXgKGMQCCaidX+Prr2954560OY/CNl0 ul3xFBGDk8AKAhKvJ+Y5WGEsq2tzP67W2LYvciBcYlfSiA5hhwJO7d9YLGvxOCEmNPYB lYjW97bwRhDWiopL1Bd9NBbdGlIgkYQgG4uAQcTMbPlhWGnTmYtnMq3oDtTpxGkdfg/7 pmNevHRYHstMGP9MPLHpqEwB2XOyDET4ZSCDGVf00npcdLT8o1b7u1+54GJ6LGc63SNx 6jofoiw+lC+MKUsweh35grGE8jbXZNVfR34+sn5XM2uyfOaxjU7wx4TF7QtIQuiRjqGG kFoQ==
X-Received: by 10.49.85.4 with SMTP id d4mr9048044qez.10.1371417318293; Sun, 16 Jun 2013 14:15:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.67.65 with HTTP; Sun, 16 Jun 2013 14:14:58 -0700 (PDT)
In-Reply-To: <003f01ce6aaf$aabda760$0038f620$@co.in>
References: <CALiegfmtohM8Nnf34o2EqMr-jV-LaQBP7mOB5qq+7OcQO9FkSA@mail.gmail.com> <003f01ce6aaf$aabda760$0038f620$@co.in>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Sun, 16 Jun 2013 23:14:58 +0200
Message-ID: <CALiegf=U9fNPcL83TbWPQirNczZ-faHmG1R+AiPVuBLa=pfe6A@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: ALoCoQmsuzEmqFDUF1cc3PswX1A5K7FP282OvfvkS7tRxd754I7B6lOyR5RzKLsCcyMbcEpXw73e
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: Sun, 16 Jun 2013 21:15:20 -0000

2013/6/16 Parthasarathi R <partha@parthasarathi.co.in>:
> Hi Inaki,
>
> Open Item 2 comment: The current statement states that
>
>      " All SIP elements MUST implement at least one of the following:
>
>       *  Both UDP and TCP transports.
>
>       *  SIP WebSocket transport."
>
> I could not understand how this update resolve the issue in the following scenario:
>
>  SIP UA1 (WS only)----Proxy-----SIP UA2 (UDP/TCP)
>
> Here, the dialog is established with contact details for SIP UA1 & SIP UA2 as follows:
>
> 1) contact: sip:sipua1@example.com;transport=ws
> 2) contact: sip:sipua2@example.com;transport=tcp
>
> In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, how does it possible now as per the current update in Sec 5.2.4 of draft-ietf-sipcore-sip-websocket-09.


Hi Parthasarathi, this subject was heavily discussed during the past
year. It's clear that in 99% or 100% of cases, a SIP WebSocket Client
(i.e. a browser) will not be able to receive incoming WS connections
(it is not a SIP WebSocket Server) and thus, the proxy in your flow
has to perform record-routing, a *standard* mechanism defined in RFC
3261 for making your scenario feasible.

IMHO it is not so hard to assume that when SIP over WebSocket devices
are present, the proxy they connect to must perform record-routing.
The same is true for clients behind NAT.


Regards.


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

v2.23.0 | Report a Bug | By Email