Peter,
 
Picking up on your last point (allowing From to change and allowing Identity
to be used for update within a dialog), this would avoid the need to enhance
Identity to cover an identity in a response (at least as far as dialogs are
concerned). As I write this, I see some discussion from Jon and Jonathan on
this same topic. Sounds like a good thing to explore.
 
John (john.elwell@siemens.com)

________________________________

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Mataga, Peter Andrew (Peter)
Sent: 11 November 2004 06:46
To: sip@ietf.org
Subject: [Sip] Identity Update



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