Re: [Sip] I-D Action:draft-worley-references-01.txt

["Dale Worley" <dworley at nortel.com>]

On Tue, 2008-12-02 at 11:59 +0100, Ian Elz wrote:
> Section 3.2 Attended Transfers
> 
> In F8, INVITE to Carol you have included a References header with
> “rel-xfer”.
> 
> How does Bob’s UA know to include this header at this time?  Bob has
> an existing session with Alice but at the time of the INVITE to Carol,
> F8, the UA does not know that a transfer is intended. The INVITE may
> be an enquiry call with no intent to transfer. Are you proposing that
> all INVITE requests when you have another session on hold will include
> this header in case you decide to transfer later?

In the phones that I am familiar with, the first step of the
consultative transfer process (putting the first leg on hold) is done by
invoking a specific consultative transfer operation.  In this case, the
phone can annotate the INVITE of the second leg as being part of a
consultative transfer process.

I had not thought of the case were the phone was not aware that a
consultative transfer was in progress until after the second leg had
been established.  I suppose that in this case, we could rely on the
remaining messages in the consultative transfer process to carry the
dialog correlations (section 3.2):

   An attended transfer normally involves three different dialogs.  If
   the transfer completes, and the REFER that completes the transfer has
   a References header, the References header in the REFER and the
   Replaces header in the resulting INVITE will suffice to connect the
   three dialogs.

(Although that text is not correct:  The REFER does not need a
References header.  The INVITE starting the third (final) dialog will
contain a References header naming the leg that carried the REFER, and
it will also carry a Replaces header (derived from the Replaces
header-parameter in the Refer-To URI of the REFER) that names the other
leg.)

> Section 3.3 Call Pick-up
> 
> F3 is a Subscribe using the dialog event package. RFC 4235 requires
> that the dialog event package includes a Call-id and a To-tag.  Am I
> missing something here? Perhaps there is another request which is not
> included in your diagram? 
> 
> Can you please clarify?

I'm not sure I understand what you mean.  The dialog event package will
be the body of the NOTIFY (F5), which is not illustrated.  The SUBSCRIBE
(F3) is illustrated with a Call-Id and from-tag.  (It has no to-tag
because it is out-of-dialog.)

Dale


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip