Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Apr 2003 17:18:26 +0100

I had only two replies to this question (see below) when I raised it a few
weeks ago, so I still don't know what conclusions to draw.
 
Brett Tate (4th April) commented on solution 4 (sending UPDATE with new
asserted ID), saying that this is valid although not explicitly documented.
 
Francois Audet (4th April) supported the use of a new INVITE with Replaces
header (and Supported header to ensure that INVITE is rejected if Replaces
not supported).
 
Personally I tend to favour sending UPDATE with a new asserted ID , but I
would like to gain more confidence that this would be acceptable to the
community before proceeding in that direction. Failing that I would go for a
new INVITE with Replaces header, but I believe the overheads would be
somewhat greater.
 
John Elwell ( [email-masked] <mailto:[email-masked]> )

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: 03 April 2003 22:18
To: [email-masked]
Subject: [Sipping] Impact on SIP of transfer in QSIG network

There has been some discussion in the past on this list concerning the
situation where call transfer takes place in a QSIG network and the impact
of this on a party in a SIP network. The outcome was inconclusive, and
talking to a couple of you at IETF56 I found that the original problem had
not been explained too well. I attempt below to set out the problem and
potential solutions.

The problem: 

A transferor in a QSIG network transfers a call and EITHER the transferee OR
the transfer target is a SIP UA. Prior to transfer there is a call linking
the SIP UA via a gateway with the QSIG transferor. After transfer there is a
call linking the SIP UA via the same gateway with the third party. If no SIP
action is taken, the original dialog will remain in place between the SIP UA
and the gateway. Note that SIP REFER is not involved - the equivalent takes
place within the QSIG network.

The problem with this is that the SIP UA receives no information about the
change of partner in the conversation. In particular, if the SIP UA
originally received the identity of the original partner by means of
asserted or authenticated identity from the gateway, that information will
no longer be valid and needs to be updated.

Potential solutions: 

1. Do nothing. This has a significant disadvantage that information sent to
the SIP UA at dialog establishment time is not updated.

2. Change the From or To header (depending on direction of dialog) leaving
the tag unchanged. This has all the disadvantages of relying on From/To for
identity at dialog establishment time. It is unsatisfactory if the SIP UA
had previously obtained its identify from another source (e.g.,
P-Asserted-Identity) rather than From/To.

3. Send Re-INVITE with new asserted or authenticated ID to SIP UA, but no
change of session parameters. I believe this may be a misuse of Re-INVITE
and it is unclear how UAs would react.

4. Send UPDATE with new asserted ID. Same remarks as above. 

5. Send INVITE (new dialog) with Replaces header and Required header
(Replaces required). This would be rejected by a UA that does not support
the Replaces header.

6. Send INFO with new identity information (e.g, P-Asserted-Identity). I
don't need to mention the concerns about INFO that have been expressed in
the past.

I would welcome comments on the above and any new proposals. 

John Elwell ([email-masked]) 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 Apr 2003 22:47:35 -0700

Just to make sure I understand the problem ... The main thing this
information is used for is to update the display on the users phone so they
understand who they are speaking too?