Subject: [Sip] Identity Update

From: "Mataga, Peter Andrew \(Peter\)" <[email-masked]>
Date: Thu, 11 Nov 2004 01:45:31 -0500

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 16 Nov 2004 12:06:40 +0000

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 ([email-masked])

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mataga, Peter Andrew (Peter)
Sent: 11 November 2004 06:46
To: [email-masked]
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:

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:

      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

Avaya, Inc.