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

From: "Francois Audet" <[email-masked]>
Date: Thu, 3 Apr 2003 17:05:39 -0800

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]] 
>
> 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.

My take is that this is exactly what the Replaces header was intented to do
(it even
mentions the attended transfer case).

It is up to the transferor to decide if the Required header should be
included or not.

It it is included, it means that the transferor prefers that the transfer
fails than
not updating the other party's information.

If not included, it means that it is willing to tolerate the fact that the
identity 
may not be updated (this happens today in traditional PBXs if there is no
protocol
to update the calling line identity and the call is locally bridged).

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2003 18:40:01 +0100

Francois,
 
In-line
 
John ([email-masked] <mailto:[email-masked]> )

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: 04 April 2003 02:06
To: 'Elwell, John'; [email-masked]'
Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network

> From: Elwell, John [mailto:[email-masked]
<mailto:[email-masked]> ] 

It it is included, it means that the transferor prefers that the transfer
fails than 
not updating the other party's information. 
[JRE] The transfer has already taken place in the QSIG network, and
therefore there is no way of making it fail. The gateway is just trying to
report to the SIP UA the fact that transfer has occurred. The point of the
Required header is to prevent the new INVITE being treated as a new call
rather than a replacement for the existing call.

If not included, it means that it is willing to tolerate the fact that the
identity 
may not be updated (this happens today in traditional PBXs if there is no
protocol 
to update the calling line identity and the call is locally bridged). 
[JRE] If Required is not included a UA that does not support Replaces will
treat the INVITE request as a new dialog and take some undesirable action,
e.g., making it wait on busy. Therefore I think Required is essential.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 4 Apr 2003 09:59:04 -0800

Thanks. Agreed.

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Friday, April 04, 2003 09:40
To: Audet, Francois [SC100:4K02:EXCH]; [email-masked]'
Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network

Francois,
 
In-line

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 25 Apr 2003 08:03:50 +0100

Cullen,

Yes, this is correct.

John

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: 25 April 2003 06:48
> To: Elwell, John; [email-masked]'
> Subject: Re: [Sipping] Impact on SIP of transfer in QSIG network
> 
> 
> 
> 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?
> 
> 
> On 4/24/03 9:18 AM, "Elwell, John" <[email-masked]> wrote:
> 
> > 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]> )
> > 
> > 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.
> > 
> > (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
> > 
> 
_______________________________________________
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