[Sip] Identity Update

"Mataga, Peter Andrew \(Peter\)" <mataga@avaya.com> Thu, 11 November 2004 06:49 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22120 for <sip-web-archive@ietf.org>; Thu, 11 Nov 2004 01:49:55 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS8nQ-00028Z-HJ for sip-web-archive@ietf.org; Thu, 11 Nov 2004 01:51:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS8ii-0004rM-0H; Thu, 11 Nov 2004 01:46:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS8i7-0004jU-Jg for sip@megatron.ietf.org; Thu, 11 Nov 2004 01:45:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21910 for <sip@ietf.org>; Thu, 11 Nov 2004 01:45:34 -0500 (EST)
Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS8jD-00024W-Rj for sip@ietf.org; Thu, 11 Nov 2004 01:46:44 -0500
Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iAB6hgEr022606 for <sip@ietf.org>; Thu, 11 Nov 2004 01:43:42 -0500 (EST)
Received: from nj7001avexu1.global.avaya.com (h135-11-150-101.avaya.com [135.11.150.101]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iAB6hfEr022580 for <sip@ietf.org>; Thu, 11 Nov 2004 01:43:41 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 11 Nov 2004 01:45:31 -0500
Message-ID: <D96F15912762BA46B00CED7E454FBD9B0A57BE43@nj7001avexu1>
Thread-Topic: Identity Update
Thread-Index: AcTHugi213TxC2u2R2m3k2zOs+IWAw==
From: "Mataga, Peter Andrew \(Peter\)" <mataga@avaya.com>
To: <sip@ietf.org>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d
Subject: [Sip] Identity Update
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0442375853=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98

There has been a lot of discussion in the past on the method of
indicating a change of identity to a UA, as an explicit user action at
the remote UA, because of transfer within a legacy network or by 3PCC in
a B2BUA, or even because of aliasing, forwarding or
redirection+recursion within a target domain when there is no mechanism
to indicate identity in a response. At San Diego the topic was revisited
with 3 options on the table:

      1) Use of INVITE/Replaces as a kind of self-transfer

      2) Changing the From header during a dialog

      3) Inventing a new header

Based on the arguments put forward during that session, there was a hum
in favor of INVITE/Replaces as the only mechanism supported. 

 

On reflection, I don't think all the issues were aired at the time or in
the small amount of subsequent list discussion. The INVITE/Replaces
mechanism certainly has some appealing similarities to other scenarios
(particularly the pure SIP transfer case, of course). I don't know that
these are compelling when the application is to update information about
a single session, and it seems to me there are going to be cases where
it is not the most efficient or convenient way of doing so. Some
specific issues:

 

1) How does the SDP in the INVITE/Replaces relate to the media session
for the original dialog? There are more possibilities than normal
because the new dialog has the same participants as the old:

      a) Same SDP session ID and version

      b) Same SDP session ID, new version

      c) New SDP session

I personally would find a) and b) a bit odd because they mean that the
media session migrates from one SIP dialog to another. Not mentioned in
the Replaces spec as far as I can see, though not ruled out either, I
suppose. I'm not sure what everyone involved in the discussions had in
mind (or what implementations might do in cases a) and b) ...).

 

2) I seem to recall claims that INVITE/Replaces would not introduce
significant loss of efficiency compared with UPDATE (or re-INVITE). If
case c) is the only reasonable one above, this may not be so, since QoS
and media encryption negotiation could be necessary. (It might even be
the case that the new request fails call admission, even though the
intent is to reuse the resources already allocated to the original call,
because the entity making the decision does not know this is a
replacement.) An in-dialog update mechanism might be able to avoid this.
Indeed, with John Elwell's proposed amendments to the relevant RFCs,
there might be no mention of media session parameters at all. I think
this more lightweight procedure should at least be possible.

 

3) INVITE/Replaces does not necessarily pass through the same
intermediaries as the original dialog. While this has to be dealt with
in other scenarios (and some in the WG appear to regard this as a Good
Thing), applications that like to "misuse" dialog stickiness will surely
find it at least convenient to be in the path of the
post-identity-change session. Presumably the answer to this is for such
an application to be a B2BUA that provides GRUU+crypto-grid Contacts
such that an INV/R from either side will pass through the application -
but such a B2BUA is not transparent to the mechanism proposed in
draft-ietf-sip-identity.

 

4) The hum preference for INVITE/Replaces seemed in large part to be
motivated by difficulties with the From header. Since there may be other
state information that will need updating in the future, it would be a
bad idea if the adoption of INVITE/Replaces for updating From were to be
taken as a precedent for any other state update, which would not be
bound by this restriction. A consistent and efficient way of updating
state information is required, and INVITE/Replaces doesn't meet the
efficiency criterion. The second hum choice was to introduce another
header. This would work, at the cost of a certain amount of redundancy
with From. In particular, draft-ietf-sip-identity would need enhancing
to allow authentication of the new header as well as (or instead of) the
>From header.

 

5) All of which leads back to the least-favorite hum choice, which I
feel is the best - to allow From to change. The motivation in 3261 for
keeping the From URI immutable was (temporary) 2543-compatibility, and
there is pretty clear language about not depending on that feature. I
question whether there are 2543-only endpoints out there that are
capable of deployment in realistic environments (that require SIPS and
GRUU support for INVITE/Replaces authorization, for example). As pointed
out in San Diego, the worst that would happen would be that a
2543-compliant UA would reject the re-INVITE or UPDATE with a 481. If
the intent is at some point to follow through on the threat in 3261 to
allow From to be changed, why not do it now, and allow Identity to be
used for update within a dialog?

 

Peter.

 

Peter Mataga

Converged Systems Division

Avaya, Inc.

 

 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip