Subject: Re: [Sip] Questions on the draft on the Replaces header

From: [email-masked]
Date: Fri, 25 Oct 2002 09:12:09 +0200

Rohan,

I understand that REFER, which includes the Refer-To header, is sufficient
to get B to establish a session with C. If I understand the REFER draft 
correctly, this has no impact on the session between A and B Therefore, at 

some point in time, B will have two sessions: on with A, and one with B.

I think that this leads to a situation in which it is not clear what B 
will 
do:

- will it mix the media from the two sessions?
- to which of the two sessions will it listen?
- to which of the two sessions will it talk?

The latter two can be influenced by A by modifying the session (e.g. put 
it
on hold). 

If it is A's intention to effect a transfer, it could do this implicitely 
by 
terminating its session with B. However, B then only has implicit 
knowledge 
(the fact that its session with A was terminated) that A probably intended 

to transfer its session with B to C.

The reason for adding the Replaces header to the REFER would be to make it
_explicit_ for B to replace its session with A by a session with C.

I realise that this somewhat changes the semantics of the Replaces header 
in 
the current proposal, but probably not by much. The current draft 
describes 
the use of the Replaces header in combination with an INVITE request only. 

Adding additional semantics for its use in combination with a REFER 
request 
would not seem to present a major impact. In particular, if the semantics
of the Replaces header are "replace the dialog/session on which this 
header
is received with the dialog/session specified in the Replaces header", 
both
situations would seem to be covered.

Regards,

Frank

Rohan Mahy <[email-masked]>
Sent by: [email-masked]
2002-10-25 00:14

        To:     Frank Derks/HVS/BE/PHILIPS@EMEA2
        cc:     [email-masked]
        Subject:        Re: [Sip] Questions on the draft on the Replaces header
        Classification: 

Hi,

If I understand your message correctly, I believe you are trying to add 
additional semantics to Replaces which are not necessary to accomplish 
what I believe you want to achieve.

If A has an existing session with C using a call-id of foo, I think you 
are asking for A to send a REFER that causes B to send an INVITE to C, 
such that the INVITE contains a Replaces header.  This would cause a 
new session from B to C to replace the old session from A to C.

To do this A sends a REFER with the following Refer-To header:

REFER sip:B SIP/2.0
Refer-To: <sip:C?Replaces=foo>

This causes B to generate an INVITE of the following form:

INVITE sip:C SIP/2.0
Replaces: foo

Headers in the REFER request are orthogonal to headers in the triggered 
request.  Headers  intended for inclusion in the triggered request are 
included in the Refer-To URI.

I hope this answers your question.

thanks,
-rohan

On Thursday, October 24, 2002, at 08:03 AM, [email-masked] 
wrote:

> The Replaces header draft
> (http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt),
> states that this header is only defined for INVITE requests (section 
> 6.1).
> The Overview
> section (section 2), however, states that it is frequently used in
> combination with the
> REFER method as used in call transfer. Although the latter does not 
> imply
> that a Replaces
> header could be used in a REFER request, it does seem to hint in that
> direction.
>
> Especially in the case of call transfer, it would be useful if it were
> allowed to use the
> Replaces header in a REFER request. The reasoning behind this is the
> following.
>
> Receiving a REFER request, is a request to _also_ contact the 
> destination
> contained in the
> Refer-To header. It has no implications for the Dialog (or the 
> Session) on
> which the REFER
> was sent. This means that it is up to the recipient of the REFER 
> request,
> to decide on the
> action(s) it is going to take after having contacted the indicated
> destination. I.e. it is
> neither explicitely, nor implicitely conveyed that a transfer should 
> take
> place. If this
> does take place, this is up to the endpoint that received the REFER
> request. This is
> outside the control of the endpoint that sent the REFER request.
>
> If it were allowed to use the Replaces header in a REFER request, it 
> would
> become possible
> to explicitely effect a transfer. Assuming that the endpoint sending 
> the
> REFER request has
> a Session with both parties that it wishes to transfer the call to, 
> such a
> REFER would be
> used as follows. The REFER request will contain a Refer-To header to
> indicate the endpoint
> to which the Session should be transferred. I.e. the endpoint that 
> should
> be contacted by
> the recipient of the REFER request. The Replaces header contains 
> details
> about the Session
> that the sender of the REFER request has with the party to which that
> Session should be
> transferred. The recipient of the REFER copies this header into the 
> INVITE
> request that
> it sends to establish the transfer call. The latter is, what I believe,
> described in the
> current Replaces draft.
>
> Any opinions on this?
>
>
> Regards,
>
> Frank
>
> _______________________________________________
> 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

_______________________________________________
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

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Fri, 25 Oct 2002 09:04:06 -0700

Hi,

This topic will be covered in the cc-transfer draft.  Basically, it is 
A's responsibility to terminate its session with B.  How B selects 
which session has "focus" is an implementation issue, but one that the 
transfer draft will discuss.

thanks,
-rohan