Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-05.txt

From: [email-masked]
Date: Thu, 06 Jun 2002 07:33:58 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: The SIP Refer Method
	Author(s)	: R. Sparks
	Filename	: draft-ietf-sip-refer-05.txt
	Pages		: 17
	Date		: 05-Jun-02
	
This document defines the REFER method.  This SIP extension requests
that the recipient REFER to a resource provided in the request.  This
can be used to enable many applications, including Call Transfer.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-refer-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-refer-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Jun 2002 18:04:29 -0400

I have a couple of questions - not unique to this version of the draft, equally applicable to them all I think. The following is from section 2:

   A REFER request MAY be placed outside the scope of a dialog created
   with an INVITE.  REFER MAY be Record-Routed, hence MUST contain a
   single Contact header field value.  REFERs occurring inside an
   existing dialog MUST follow the Route/Record-Route logic of that
   dialog.  REFERs occurring outside an existing dialog effectively
   create a new dialog following the behavior of SUBSCRIBE specified in
   [2].

1) WRT the last sentence above - subscribe dialogs have an expiration time. Suppose the refer still hasn't completed by the time the dialog is about to expire. (Perhaps an
INVITE was sent and a Ringing was returned, but the call hasn't yet succeeded or failed.) How would the UA go about refreshing the subscription? (A new REFER in the same
dialog doesn't seem right, but neither does a SUBSCRIBE.) 

Even if the dialog isn't about to expire, I might want to refresh as a way to verify that the other end is still alive, in case no notifies have been received recently. (I
should expect notifies as often as the corresponding INVITE can expect responses.)

2) The first sentence implies that a REFER *MAY* be placed *inside* the scope of a dialog created by an invite. In fact this is an important use case. If so, are the
subsequent NOTIFY messages returned in the context of that same dialog? (If so, presumably that dialog can be refreshed with reINVITEs.)

	Paul

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: 06 Jun 2002 21:11:03 -0500

Inline

> dialog doesn't seem right, but neither does a SUBSCRIBE.) 

I know what you're trying to say, but I cant follow the description
of the scenario you lay out.

REFER creates a subscription just like SUBSCRIBE does. That means the
subscription can be refreshed with a resubscribe as in 3265 or 
terminated with an unsubscribe. 

It has become clear from private comments (seems it was about ripe
for people to rediscover this particular side effect of an implicit
subscription) that more clarification needs to go into the draft.
Look for a revision early next week.

> should expect notifies as often as the corresponding INVITE can expect responses.
> 

This is _the_ most important use case - the first standardized use
of REFER uses exactly this case. The draft as currently written
addresses this. Any notifies come with dialog identifiers matching
the REFER. If the REFER was already in a dialog, the NOTIFYs will
also be.

Now, DO NOT mistake lifetime of subscription with lifetime of the
INVITE dialog. They are separate. You would renew the subscription
with resubscribe, not reinvite.

There are issues with knowing how long the subscription created with
a REFER is good for (until you receive the first Notify, which
will let you know for sure). We've hashed through these on the list many
times. The clarifications in next weeks revision will make will
document these explicitly in the draft so we don't thrash on them
yet another time.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jun 2002 10:11:33 -0400

> of the scenario you lay out.

Never mind. You got the point.

> terminated with an unsubscribe.

It was clear that the subscription is created, but not that it can be refreshed with resubscribe.

> Look for a revision early next week.

I'm happy to wait, and cut off further discussion now, for the sake of everybody.

> with resubscribe, not reinvite.

I just went back and re-read draft-ietf-sip-events-05, and realized I was remembering the details wrong. I now see that dialogs don't expire - individual subscriptions
within a dialog expire. That is my mistake, and is clear enough.

But I think more about subscription identity, duration, and renewal would be helpful here - it is a little unusual because of the implicit initial subscription.

I presume the response to the REFER should contain an Expires header that defines the duration of the subscription. That will permit the UAC to generate a specific
SUBSCRIBE to renew before the subscription expires.

That does however lead to another question. In 6.3.3 you say that 

   for the second and subsequent REFER requests a UA receives in a
   given dialog, it MUST include an id parameter[2] in the Event header
   field of each NOTIFY containing the sequence number (the number from
   the CSeq header field value) of the REFER this NOTIFY is associated
   with.

This id is of course also used for refreshes, and is predictable even prior to receipt of the first NOTIFY. (Though it might not always be convenient to remember if this is
the first implicit subscription in a dialog. It would be easier to predict if the Event header could be returned in the response to the REFER. But that is currently
illegal.)

But what happens after the first refresh? The refresh will have a unique CSeq value. Does that result in assigning a new id for the subscription? Presumably not, but worth
stating explicitly.

	Paul