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

[Rohan Mahy <rohan@cisco.com>]

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, frank.derks@philips.com 
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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip