IETF Logo Mail Archive

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

"Parthasarathi R" <partha@parthasarathi.co.in> Tue, 25 June 2013 00:41 UTC

Return-Path: <partha@parthasarathi.co.in>
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 4131321F9412 for <sipcore@ietfa.amsl.com>; Mon, 24 Jun 2013 17:41:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Level:
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599]
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 i-QRK+zw7I5C for <sipcore@ietfa.amsl.com>; Mon, 24 Jun 2013 17:41:47 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.152]) by ietfa.amsl.com (Postfix) with ESMTP id D2F3621F8FE5 for <sipcore@ietf.org>; Mon, 24 Jun 2013 17:41:47 -0700 (PDT)
Received: from userPC (unknown [122.179.33.109]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 9B11086859C; Tue, 25 Jun 2013 00:41:39 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1372120903; bh=aWGXdrxp6LL3VxWiQWv5BU0MraFF0Ut+OMZZsK3nh+I=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=LjPaRSwqkC0A/JeE+HaWCvzZOX3Zo/yGVVLvRGiIQOFfnrhsRHrwT6kKzkp7diHNo sM5EzCPMl4qm0sCrlv4oVcUxF1Rass5ao67q0DxaMQae7EjofZN10us6O31GCxUuU9 XsxEMull6kiJW92oqPzkDFpz+UxJ3rLvJNJbhztE=
From: Parthasarathi R <partha@parthasarathi.co.in>
To: 'Paul Kyzivat' <pkyzivat@alum.mit.edu>, sipcore@ietf.org
References: <CALiegfmtohM8Nnf34o2EqMr-jV-LaQBP7mOB5qq+7OcQO9FkSA@mail.gmail.com> <003f01ce6aaf$aabda760$0038f620$@co.in> <CALiegfn=KrEsOT+HGkCpfkS3C7Tc0Jko6kautCHk3sP8zHrzVw@mail.gmail.com> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <CALiegfnPeFf751QHLoeT_jO0u1LROtvkqseE7QcAZvLgSiqVZQ@mail.gmail.com> <E54AEADE791D51469F45E7FBB964391505C964@SGSIMBX001.nsn-intra.net> <019a01ce6d24$8ee95670$acbc0350$@co.in> <CALiegfkFVJgNNLJat+3v4JqXz_=OwLPTDtR6J55dRLmiH8OgFg@mail.gmail.com> <51C3267F.8040709@alum.mit.edu>
In-Reply-To: <51C3267F.8040709@alum.mit.edu>
Date: Tue, 25 Jun 2013 06:11:35 +0530
Message-ID: <002301ce713c$c2672880$47357980$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac5tzvKHGxjGwUQ2QmGbGID1iM+b0gDaw1ng
Content-Language: en-us
X-CTCH-RefID: str=0001.0A0C0205.51C8E747.000A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.156
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: Tue, 25 Jun 2013 00:41:52 -0000

Paul,

I think that we are talking about two problems here

1) SIP routing issue because of SIP WebSocket Client has only WebSocket as a transport (Browser scenario)
	a) Solution: Record-route header has to be added by SIP WebSocket Server.
 
2) How will SIP WebSocket Server know that SIP WebSocket client supports only SIP WebSocket as a transport? (Non-browser scenario)
	a) AFAIK, there is no other environment other than browser has the limitation of not supporting UDP & TCP. In case any other environment exists, Please let me know.
	b) The beauty of RFC 3261 is that there is no need to negotiate the set of "SIP" transport protocol as it mandates for UDP, TCP. I agree that it is an open item how to represent the list of transport supported by a SIP UA in case of supporting WebSocket only transport scenario. But I'm not sure whether this WG is interested in solving this issue. We need to here from more folks and its relevant usecases.

Thanks
Partha

> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: Thursday, June 20, 2013 9:28 PM
> To: sipcore@ietf.org
> Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-
> 09
> 
> On 6/19/13 6:05 PM, Iñaki Baz Castillo wrote:
> > 2013/6/19 Parthasarathi R <partha@parthasarathi.co.in>:
> >>
> >> Just adding to Ranjit mentioned. The text similar to the following
> has to be added. "Record-route header MUST be added by SIP WebSocket
> Server in case WebSocket is the only supported SIP transport between
> SIP WebSocket client & server and SIP WebSocket server acts as SIP
> proxy"
> >
> > That is just true in case the client is a web browser (a SIP WS
> Client
> > but not a SIP WS Server so it can not receive incoming WS
> > connections). So the text would be:
> >
> > "Record-route header MUST be added by SIP WebSocket Server in case
> > WebSocket is the only supported SIP transport between client and
> > server, the server acts as SIP proxy, and the client is a SIP
> > WebSocket Client (but not a SIP WebSocket Server so it can not accept
> > incoming WebSocket connections)."
> 
> How will the server know that the client is not capable of being a
> WebSocket Server?
> 
> I guess in many cases it might be able to know that because the client
> is a browser being controlled by scripting from the server. But in
> other
> cases ISTM that it just won't know.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

v2.23.0 | Report a Bug | By Email