Re: [Sipping-tispan] Re: TIP/TIR requirements

Miguel Garcia <Miguel.An.Garcia@nokia.com> Fri, 09 September 2005 07:18 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDd9E-0005qS-J4; Fri, 09 Sep 2005 03:18:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDd9A-0005qM-9V for sipping-tispan@megatron.ietf.org; Fri, 09 Sep 2005 03:18:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14382 for <sipping-tispan@ietf.org>; Fri, 9 Sep 2005 03:18:02 -0400 (EDT)
Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDdCh-0008NN-1f for sipping-tispan@ietf.org; Fri, 09 Sep 2005 03:21:43 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j897GuaW009720; Fri, 9 Sep 2005 10:17:00 +0300
Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Sep 2005 10:17:54 +0300
Received: from [127.0.0.1] ([172.21.35.78]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Sep 2005 10:17:54 +0300
Message-ID: <43213721.2000204@nokia.com>
Date: Fri, 09 Sep 2005 10:17:53 +0300
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: GARCIN Sebastien RD-CORE-ISS <sebastien.garcin@francetelecom.com>
Subject: Re: [Sipping-tispan] Re: TIP/TIR requirements
References: <49E7012A614B024B80A7D175CB9A64EC06697404@ftrdmel1.rd.francetelecom.fr>
In-Reply-To: <49E7012A614B024B80A7D175CB9A64EC06697404@ftrdmel1.rd.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 09 Sep 2005 07:17:54.0369 (UTC) FILETIME=[98904B10:01C5B50E]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext03.nokia.com id j897GuaW009720
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e367d58950869b6582535ddf5a673488
Content-Transfer-Encoding: quoted-printable
Cc: sipping-tispan@ietf.org
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN <sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org

So can someone summarize what should be the wording of requirement 
TIP-3. It currently says.

     REQ-TIP-3:
         The identity mentioned in REQ-TIP-1 is considered an end user
         supplied information that is not asserted by the network.


/Miguel

GARCIN Sebastien RD-CORE-ISS wrote:

> Hi,
> 
> In France, we make no difference between the case where you have an enterprise network (i.e PBXs) between the user and the local exchange and the case where the ISDN user is connected directly to the exchange. We have a special arrangement in both situations, but my assumption is that we do this because we have very few ISDN subscribers.
> 
> Regards,
> sebastien 
> 
> -----Message d'origine-----
> De : sipping-tispan-bounces@ietf.org [mailto:sipping-tispan-bounces@ietf.org] De la part de Drage, Keith (Keith)
> Envoyé : jeudi 8 septembre 2005 20:39
> À : 'Miguel Garcia'; Michael Hammer (mhammer)
> Cc : sipping-tispan@ietf.org
> Objet : RE: [Sipping-tispan] Re: TIP/TIR requirements
> 
> It depends what you mean by asserted. Assertion is based on authentication and trust models between different operators.
> 
> It case it is not clear from the thread, I believe the number we are talking about is the additional number rather than the one contained in a response in the P-Asserted-Identity header. This number is represented in the PSTN world by the generic number in ISUP, and as the first presented Connected number information element when there are two presented.
> 
> The P-Asserted-Identity is only asserted to the extent that it is known to be one owned by a particular user who is making the call. The connected user has been authenticated by the connected user network. If the calling network and the connected user network are diffferent networks, the calling network trusts the connected user network in asserting that users identity. In the existing PSTN/ISDN that trust only occurs if the two networks are public networks, or if the connected user network supplies one of a set of numbers that can be validated by some supporting public network.
> 
> For the generic number, in the PSTN/ISDN, a special arrangement is supposed to exist, and while it does not say so, at least in Europe this special arrangement would only be given to operators of enterprise networks or equivalent, which does imply some degree of trust to the supplying enterprise network. It is not given to an end terminal user, and the supplying enterprise network might be expected to authenticate the end user before supplying the number, or rely on its own trust arrangements. While it cannot be policed in the signalling, it is a privilege that can be expected to be taken away if it is abused. The capability is necessary as the enterprise network may be allowed to break into the public network at a remote connect point (for tariff reasons) and the public network has insufficient knowledge to know if the number supplied really belongs to that user.
> 
> I understand North America may be more flexible in what it allows, and in contravention of the equivalent ITU-T Recommendations. As such they are therefore untrusted by other network operators.
> 
> As such it is not an equivalent of the From header. Neither is it the P-Asserted-Identity, as the trust bestowed on it is less than that which public network operators would desire.
> 
> regards
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> drage@lucent.com
> tel: +44 1793 776249
> 
> 
>>-----Original Message-----
>>From: sipping-tispan-bounces@ietf.org
>>[mailto:sipping-tispan-bounces@ietf.org]On Behalf Of Miguel Garcia
>>Sent: 07 September 2005 19:21
>>To: Michael Hammer (mhammer)
>>Cc: sipping-tispan@ietf.org; Alexeitsev, D
>>Subject: Re: [Sipping-tispan] Re: TIP/TIR requirements
>>
>>
>>I am certainly not the expert in supplementary services in the PSTN, 
>>but
>>  I have been told that this identity is never asserted by the 
>>network, so the callee can put there whatever he wants.
>>
>>During the discussions of solutions we looked at headers like 
>>Reply-To, and In-Reply-To, but their semantics are well defined and do 
>>not match the requirements.
>>
>>/Miguel
>>
>>Michael Hammer (mhammer) wrote:
>>
>>
>>>If this is not an asserted identity, then what good is it?
>>>
>>>I thought that the CLIP and COLP were complementary and identical in 
>>>type.  But, perhaps that is a subtlety I missed.
>>>
>>>Mike
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: sipping-tispan-bounces@ietf.org 
>>>>[mailto:sipping-tispan-bounces@ietf.org] On Behalf Of Miguel Garcia
>>>>Sent: Wednesday, September 07, 2005 4:03 AM
>>>>To: Schmidt, Christian
>>>>Cc: sipping-tispan@ietf.org; Alexeitsev, D
>>>>Subject: [Sipping-tispan] Re: TIP/TIR requirements
>>>>
>>>>Inline discussion.
>>>>
>>>>Schmidt, Christian wrote:
>>>>
>>>>
>>>>
>>>>>Some comments / questions concerning the TIP/TIR requirements:
>>>>>
>>>>>- What happens, when the caller is in PSTN and the callee
>>>>
>>>>provides a
>>>>
>>>>
>>>>>SIP URI as identity? Will it be translated at the gateway
>>>>
>>>>to a E.164 number?
>>>>
>>>>I don't know what people want to do in this scenario, but in my 
>>>>opinion the responsibility lies in the calee, so if the callee 
>>>>offers only a SIP URI, and not both a SIP URI and TEL URL, then the 
>>>>network shouldn't be doing this type of translations. Remember that 
>>>>this is not an asserted identity, so this should be end-to-end 
>>>>information
>>>>
>>>>
>>>>
>>>>>- TIP-1: type error: calle > callee
>>>>
>>>>Fixed.
>>>>
>>>>
>>>>
>>>>>- How to handle identity restriction from PSTN/ISDN side? 
>>
>>Sould the
>>
>>>>>gateway delete both identity information and restriction
>>>>
>>>>information
>>>>
>>>>
>>>>>in this case?
>>>>
>>>>If we build on the trust model, and if we consider that the PSTN 
>>>>Gateway trusts the IMS network, then I would say no, delete at the 
>>>>trusted/not-trusted boundary.
>>>>
>>>>
>>>>
>>>>
>>>>>EQ-TIP-4: If identity information and restriction indication is 
>>>>>included in a message, the gateway may not transfer the
>>>>
>>>>identity information.
>>>>
>>>>Is this a proposal for a new requirement? What is the actual 
>>>>requirement here? This looks like a clarification.
>>>>
>>>>/Miguel
>>>>
>>>>
>>>>>Regards,
>>>>>Christian
>>>>>
>>>>
>>>>-- 
>>>>Miguel A. Garcia           tel:+358-50-4804586
>>>>sip:miguel.an.garcia@openlaboratory.net
>>>>Nokia Research Center      Helsinki, Finland
>>>>
>>>>
>>>>_______________________________________________
>>>>Sipping-tispan mailing list
>>>>Sipping-tispan@ietf.org
>>>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>>
>>>
>>-- 
>>Miguel A. Garcia           tel:+358-50-4804586
>>sip:miguel.an.garcia@openlaboratory.net
>>Nokia Research Center      Helsinki, Finland
>>
>>
>>_______________________________________________
>>Sipping-tispan mailing list
>>Sipping-tispan@ietf.org
>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>
> 
> 
> _______________________________________________
> Sipping-tispan mailing list
> Sipping-tispan@ietf.org
> https://www1.ietf.org/mailman/listinfo/sipping-tispan

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan