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

From: "Ian Elz" <[email-masked]>
Date: Tue, 2 Dec 2008 11:59:25 +0100

Dale,

There are a couple of things in your draft on which I am not clear:

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?

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?

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
[email-masked]

_______________________________________________
Sip mailing list  https://www.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: "Dale Worley" <[email-masked]>
Date: Tue, 02 Dec 2008 22:01:33 -0500

On Tue, 2008-12-02 at 11:59 +0100, Ian Elz wrote:
> “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

---

From: "Ian Elz" <[email-masked]>
Date: Fri, 5 Dec 2008 10:34:22 +0100

Dale,

For the Call pick up I was not referring to the headers in the SUBSCRIBE
but to the Event header specifically.

RFC 4235 which defines the dialog event requires that the dialog event
has the call-id and at least the to-tag for the dialog on which the
subscription is to act (RFC 4235 Section 3.3):

E.g.

Event: dialog;call-id=536829AF35;to-tag=98153284afer

I was asking if there has been any change to the dialog event definition
which allows you to SUBSCRIBE for all dialogs on a UA.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

-----Original Message-----
From: Dale Worley [mailto:[email-masked]] 
Sent: 03 December 2008 03:02
To: SIP
Subject: Re: [Sip] I-D Action:draft-worley-references-01.txt

On Tue, 2008-12-02 at 11:59 +0100, Ian Elz wrote:
> How does Bob's UA know to include this header at this time?  Bob has

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 05 Dec 2008 13:24:50 -0500

> Event: dialog;call-id=536829AF35;to-tag=98153284afer

You mean "the Event header of a dialog event SUBSCRIBE".  A "dialog
event" (as people use the term) is the XML document described by RFC
4235.

> which allows you to SUBSCRIBE for all dialogs on a UA.

To the extent that "a UA" can be identified by a single contact URI, if
you send a SUBSCRIBE to that URI with the header "Event: dialog", then
you should receive dialog events that contain all dialogs that involve
that contact.

The problem is practice is "multi-line phones", where each line has a
different AOR and contact URI.  In that case, a SUBSCRIBE directed to
one contact URI receives dialog events for dialogs "on that one line".
There is no standardized mechanism for obtaining dialog events for all
dialogs active on a physical phone with multiple contact URIs.

Dale