RE: [Sipping-tispan] Re: TIP/TIR requirements
"Bemmel, Jeroen van (Jeroen)" <jbemmel@lucent.com> Thu, 08 September 2005 09:20 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1EDIZl-0006JR-Nj; Thu, 08 Sep 2005 05:20:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1EDIZi-0006JE-IL
for sipping-tispan@megatron.ietf.org; Thu, 08 Sep 2005 05:20: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 FAA08839
for <sipping-tispan@ietf.org>; Thu, 8 Sep 2005 05:20:03 -0400 (EDT)
Received: from ihemail2.lucent.com ([192.11.222.163])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDId0-00061i-4M
for sipping-tispan@ietf.org; Thu, 08 Sep 2005 05:23:34 -0400
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
[135.85.76.62])
by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j889JbGk018803;
Thu, 8 Sep 2005 04:19:40 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
(5.5.2657.72) id <QJWZT29N>; Thu, 8 Sep 2005 11:19:36 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550577DF2C@nl0006exch001u.nl.lucent.com>
From: "Bemmel, Jeroen van (Jeroen)" <jbemmel@lucent.com>
To: "'Jesske, R'" <R.Jesske@t-com.net>, Miguel.An.Garcia@nokia.com,
mhammer@cisco.com
Subject: RE: [Sipping-tispan] Re: TIP/TIR requirements
Date: Thu, 8 Sep 2005 11:19:36 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: sipping-tispan@ietf.org, "Alexeitsev, D" <D.Alexeitsev@t-com.net>
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
Regarding the TIP/TIR requirements:
Currently they are stated as follows (version -02d):
REQ-TIP-1:
It must be possible for the callee to indicate in a SIP response an additional identity where he is reachable for future direct communications.
REQ-TIP-2:
The identity mentioned in REQ-TIP-1 must be formatted as a SIP URI (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol," June 2002.) [2] or TEL URL (Schulzrinne, H., "The tel URI for Telephone Numbers," December 2004.) [3].
REQ-TIP-3:
The identity mentioned in REQ-TIP-1 is considered an end user supplied information that is not asserted by the network.
Some comments on this:
REQ-TIP-1 : I think this should be stated as a requirement, without refering to any particular mechanism (SIP response)
Proposed rewording: "When the TIP service is enabled, the identity of the terminating party MUST be presented to the caller"
REQ-TIP-3: Instead of saying that it is not asserted by the network, I would propose the following wording:
"The identity mentioned in REQ-TIP-1 MUST be supplied by the callee and MUST be forwarded transparently by the network"
In addition, I think there are several requirements missing here:
REQ-TIP-4: "The terminating identity MUST uniquely identify the terminating party, and MUST be usable to contact this party directly for future communications". The period of validity is subject to discussion
In solution terms this rules out private IP addresses, and public IP addresses allocated dynamically (e.g. through DHCP) would need to be valid for a sufficiently long period of time (when used).
For TIR:
REQ-TIR-1: "When the TIR service is enabled, the originating party MUST NOT receive any information that can be used to uniquely identify (and contact) the terminating party"
In solution terms this leads to a B2BUA-based approach, since the last Via header, the Contact header and potentially other headers all contain information about the terminating party.
Regards,
Jeroen van Bemmel, Lucent
_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan
- [Sipping-tispan] TIP/TIR requirements Schmidt, Christian
- [Sipping-tispan] Re: TIP/TIR requirements Miguel Garcia
- RE: [Sipping-tispan] Re: TIP/TIR requirements Michael Hammer (mhammer)
- Re: [Sipping-tispan] Re: TIP/TIR requirements Miguel Garcia
- RE: [Sipping-tispan] Re: TIP/TIR requirements Michael Hammer (mhammer)
- Re: [Sipping-tispan] Re: TIP/TIR requirements Miguel Garcia
- RE: [Sipping-tispan] Re: TIP/TIR requirements Bemmel, Jeroen van (Jeroen)
- RE: [Sipping-tispan] Re: TIP/TIR requirements Drage, Keith (Keith)
- RE: [Sipping-tispan] Re: TIP/TIR requirements GARCIN Sebastien RD-CORE-ISS
- Re: [Sipping-tispan] Re: TIP/TIR requirements Miguel Garcia
- Re: [Sipping-tispan] Re: TIP/TIR requirements Miguel Garcia