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

From: "Elwell, John" <[email-masked]>
Date: Thu, 03 Apr 2003 22:18:25 +0100

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])

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 3 Apr 2003 19:33:40 -0500

> 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: 
>
> 4. Send UPDATE with new asserted ID.

Solution 4 is valid although it potentially 
has not been explicitly documented.  Using 
UPDATE or a re-INVITE with a new display-name 
is potentially also valid.

RFC 3311 documents that UPDATE
can be used to update most any header
that is valid during an invite dialog.
The session timer draft is using UPDATE
to update the Session-Expires.  RFC 3311
uses UPDATE to update the body, Contact, 
Allow, Call-Info, etcetera.  (See section 8.)

Unfortunately RFC 3311 did not define
a header to help identify which headers
are trying to be updated.  If it did,
it might be easier to communicate which
things should be updated and which things
were successfully updated.

_______________________________________________
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