[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Questions on the draft on the Replaces header
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 <rohan@cisco.com>
Sent by: sip-admin@ietf.org
2002-10-25 00:14
To: Frank Derks/HVS/BE/PHILIPS@EMEA2
cc: sip@ietf.org
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, 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
_______________________________________________
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