IETF Logo Mail Archive

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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 26 June 2013 15:14 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 5593321E8090 for <sipcore@ietfa.amsl.com>; Wed, 26 Jun 2013 08:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.119
X-Spam-Level:
X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 J+7YYIs1XixC for <sipcore@ietfa.amsl.com>; Wed, 26 Jun 2013 08:13:59 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id E10FF21E8063 for <sipcore@ietf.org>; Wed, 26 Jun 2013 08:13:55 -0700 (PDT)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta01.westchester.pa.mail.comcast.net with comcast id t15U1l00316LCl0513Dvl0; Wed, 26 Jun 2013 15:13:55 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id t3Dv1l00E3ZTu2S3S3DvFG; Wed, 26 Jun 2013 15:13:55 +0000
Message-ID: <51CB0532.3020107@alum.mit.edu>
Date: Wed, 26 Jun 2013 11:13:54 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Parthasarathi R <partha@parthasarathi.co.in>
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> <002301ce713c$c2672880$47357980$@co.in>
In-Reply-To: <002301ce713c$c2672880$47357980$@co.in>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372259635; bh=m7BpWPq2wsJ31blmck/uJzubmwmxiE8pgXi/8HvYgWE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hSlTlUQikiYTxKKVSX3xNspw0rFb+u/eYrzPaBH7sEkRAWBWjJQerqSG82KVQqfPp A4KBZB00v2Aqh/uy8ADlSAVRJknotEey6oi6iaoILXpTUQQW2E7ZXahBcWBPzvZwV/ oBiLaePx1iG+gUNu/DaaVH9bakPZOf+ARqLvT3LeqFYl9R6l33PyWaALS2Z9vqYAcu 1c5eqlcsmk1pXx2p9r75hTY1j+6ewKR4UltSRVIvp6DJtaNlO4iVN/Sj2ja/Im5SmF jrxWO4tHEdS7AW0BkIj68wfwk/0Tka61GrhT2SiUrPGRIbdFVhSCMNvm7XCUPcE6TZ P2LlgI8n/+sLw==
Cc: 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: Wed, 26 Jun 2013 15:14:04 -0000

Partha,

You addressed your reply to me. But I just posed the question, not the 
answer. I'm waiting for those who proposed the language to clarify it.

The real issue is: how can a websocket server ever decide that it 
*doesn't* need to R-R?

	Thanks,
	Paul

On 6/24/13 8:41 PM, Parthasarathi R wrote:
> 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