IETF Logo Mail Archive

[sipcore] SIP/websocket: SIP Identity question

Binod <binod.pg@oracle.com> Mon, 21 October 2013 04:20 UTC

Return-Path: <binod.pg@oracle.com>
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 1441211E8147 for <sipcore@ietfa.amsl.com>; Sun, 20 Oct 2013 21:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 67XT3a8Os+i1 for <sipcore@ietfa.amsl.com>; Sun, 20 Oct 2013 21:20:06 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8A611E8132 for <sipcore@ietf.org>; Sun, 20 Oct 2013 21:20:06 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9L4K4Ko023690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <sipcore@ietf.org>; Mon, 21 Oct 2013 04:20:05 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9L4K3Ca008764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <sipcore@ietf.org>; Mon, 21 Oct 2013 04:20:04 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9L4K3Nw018318 for <sipcore@ietf.org>; Mon, 21 Oct 2013 04:20:03 GMT
Received: from [10.178.246.199] (/10.178.246.199) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 20 Oct 2013 21:20:03 -0700
Message-ID: <5264AB70.7000408@oracle.com>
Date: Mon, 21 Oct 2013 09:50:00 +0530
From: Binod <binod.pg@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: sipcore@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [sipcore] SIP/websocket: SIP Identity question
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, 21 Oct 2013 04:20:13 -0000

Hi,

Section 7 of sip/websocket says the following.

    If SIP Digest authentication is not requested for SIP requests coming
    from the SIP WebSocket Client, then the SIP WebSocket Server MUST
    authorize SIP requests based on a previous Web or WebSocket login /
    authentication procedure, and MUST validate that the SIP identity in
    those SIP requests match the SIP identity associated to the WebSocket
    connection.

I assume, the "SIP identity associated to the WebSocket connection" is not
exactly the same as the "web identity" associated with the websocket connection.

The RFC draft does not explain how the SIP WebSocket Server maps the
"web identity" (example: the username with which user logs into a website)
to the "sip identity".

So, the "matching" specified in section 7, happens "after" a potential mapping
between "web identity" and "sip identity".

Did I get it right?

Hope draft is not mandating that username with which user logs into the website
must match with the sip identity present in the SIP request.

thanks,
Binod.

v2.23.0 | Report a Bug | By Email