Subject: [Sip] Observations on use of REFER

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 19 Sep 2001 16:04:40 -0400

Expiry of REFER-Created Subscription:

Am I right in supposing that the only way the implicit subscription created
by REFER expires is by explicit unsubscription?  Or is it possible to say
that if a REFER is issued within the context of a call-leg, the subscription
expires when the call-leg does?

Correlation of NOTIFYs:

I have a situation where the same UAC issues two different REFERs to the
same UAS within the same call-leg.  Naturally the order of the returned
NOTIFY requests is indeterminate.  AFAIK it appears I have to specify that
the body of the NOTIFY include not only the status line, but also the To:
header from the final response, in order to let the initiating UAC know
which REFER it is related to.  If this is seen as a general need, perhaps
the minimum information specified in 3.6.2.2 of draft-..-refer might specify
it.

I did agonize over whether the returned To header should include the tag (it
is part of the information needed to hijack the call-leg triggered by the
REFER), but I'm not sure whether the phrase "... MAY include more of a SIP
message ..." in 3.6.2.2 requires that if a header is included it is included
in its entirety..

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

---

From: "Lessing, FrancoisX" <[email-masked]>
Date: Thu, 20 Sep 2001 10:30:13 -0700

Hi,

The 3rd paragraph of section 6 in draft-ietf-sip-cc-transfer-05,  has the
following text,

"If the Transferor's agent does
   not wish to participate in the remainder of the REFER process and has
   no intention of assisting with recovery from transfer failure, it
   could emit a BYE to the Transferee as soon as the REFER transaction
   completes. "

this may be interpreted that a subscription dies with its call leg. Does this
behaviour apply in general to refer, or only cc-transfer?

Another question comes to mind, how should the Transferor 'terminate'
a REFER that was sent outside of an existing call or call leg?.

Send another REFER with Expires = 0, like with SUBSCRIBE ?
Maybe termination for this situation is not that important ?

Francois.
[email-masked]
+1-310-481-5937

Tom-PT Taylor wrote:

> Am I right in supposing that the only way the implicit subscription created by REFER expires is by
> explicit unsubscription?  Or is it possible to say that if a REFER is issued within the context of
> a call-leg, the subscription expires when the call-leg does?
>
> Correlation of NOTIFYs:
>
> I have a situation where the same UAC issues two different REFERs to the same UAS within the same
> call-leg.  Naturally the order of the returned NOTIFY requests is indeterminate.  AFAIK it appears
> I have to specify that the body of the NOTIFY include not only the status line, but also the To:
> header from the final response, in order to let the initiating UAC know which REFER it is related
> to.  If this is seen as a general need, perhaps the minimum information specified in 3.6.2.2 of
> draft-..-refer might specify it.
>
> I did agonize over whether the returned To header should include the tag (it is part of the
> information needed to hijack the call-leg triggered by the REFER), but I'm not sure whether the
> phrase "... MAY include more of a SIP message ..." in 3.6.2.2 requires that if a header is
> included it is included in its entirety..
>
> Tom Taylor

_______________________________________________
Sip mailing list  http://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: [email-masked]
Date: Thu, 20 Sep 2001 13:42:44 -0500

> Am I right in supposing that the only way the implicit subscription
> created by REFER expires is by explicit unsubscription?  Or is it
> possible to say that if a REFER is issued within the context of a
> call-leg, the subscription expires when the call-leg does?

Does this really matter? 

The Referror (playing the role of implicit subscriber) has some
period of time its willing to listen for notifies. With the implicit
subscription, it's not telling the far end how long this is. Any
notifies that arrive after that time, it 481s. If it decides to
shorten that time prematurely (because a bye was sent for example)
the net effect was if it had the shorter time in mind to begin with.

The Referred party has no clue how long something cares about getting
notified. Its only recourse is to send interesting events (of which
there may be only one) until it receives a 481 to a NOTIFY. If its
unwilling to send any more events, it just stops. At some point the
referror is going to give up on listening.

So, the two endpoints don't get trapped into any infinite 
responsibilities. The only place problems can remain is in
the middle. Will anything in the middle care about the period 
in which NOTIFYs to a REFER can occur. I can't think of why.
If they do, then the implicit subscription is a mistake.

So, setting my own distaste for the implicit subscription concept aside,
unless someone comes up with an explicit scenario where something in
the middle breaks because it doesn't know when the subscription terminates,
I propose this is a non-issue.

> NOTIFY requests is indeterminate.  AFAIK it appears I have to specify
> that the body of the NOTIFY include not only the status line, but also
> the To: header from the final response, in order to let the initiating
> UAC know which REFER it is related to.  If this is seen as a general
> need, perhaps the minimum information specified in 3.6.2.2 of

You've identified an ugly problem (and I'll point out that it's another
side-effect of the implicit subscription). How do we want to solve it?
We have the option of saying you only get one refer inside any given
call leg (just like you only get one subscription in a call leg).

Given that people are wanting to use the common call leg as the
key to admission policy for the REFER, and that recovery from a
failed transfer will likely involve a second REFER to somewhere else,
we probably do want to solve it in some fashion other than disallowing
more than one REFER. What you've proposed isn't right.  In particular,
you may not have such a To: header to play with if you REFER to a non-SIP URL.
I also feel it would be better to have the correlation show up in the signalling
instead of the payload (in case things in the middle care someday - the payload
may be e-e encrypted).

The only correlation information that'll be unique will be the CSeq of the
REFER. The refer-to URL and its derivates (like the To: header you wanted
to use) are not guaranteed to be unique - what if the two refers above
just happened to be to the same URL?

How about returning the CSeq of the REFER as a parameter on the Event
header in the NOTIFY? Something like

NOTIFY <stuff>
Event: refer; cseq=13344

> 
> I did agonize over whether the returned To header should include the tag
> (it is part of the information needed to hijack the call-leg triggered
> by the REFER), but I'm not sure whether the phrase "... MAY include more
> of a SIP message ..." in 3.6.2.2 requires that if a header is included
> it is included in its entirety..

The thing being returned only has to be syntactically valid on a per-header
basis (see the sip-mimetypes draft). Removing the tag still leaves you with
a valid To: header. There is no requirement that the sipfrag be a subset
of the response to the triggered request at all. You can build things that
way, but others don't have to. Remember the minimal implementation that
with return only 200 or 503 status lines.