Re: Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO)

Dale Worley wrote:
> On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote:
>> Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION
>> usage, or neither?
>>
>> I'm asking mainly because of REFER 481 impacts; however the answer
>> also has potential implications concerning draft-ietf-sip-info-events.
>> RFC 5057 appears to imply that it is part of the subscription usage;
>> however I'm not positive if my interpretation and/or RFC 5057 is
>> correct.
>>
>> If REFER isn't considered part of the INVITE usage, how should REFER
>> 481 be interpreted?  More specifically, should receiver of REFER 481
>> send BYE?
> 
> I would argue that the REFER is part of the INVITE usage, because REFER
> in that context is intimately related to the INVITE usage -- it is
> intended to transfer the INVITE usage/dialog transferred to a different
> destination.

Well, I guess there is that implied association. (Part of the "do what 
*I* had in mind" approach that REFER has.) Since this was never spelled 
out, it could also be simply "while this isn't part of an INVITE usage, 
if there happens to be an INVITE usage, please refer that one."

I guess the question is: would it be valid to send a REFER within an 
existing dialog that had no INVITE usage? If it were valid, presumably 
it would have the same meaning as sending one outside a dialog, except 
that the resulting subscription would share the dialog. I expect that is 
a usage it would be difficult to find in the wild.

Ah, but now I want to reconsider. Remember that REFER can take a method 
name. So, rather than referring an INVITE, I could be referring MESSAGE, 
OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the 
association to the INVITE usage is probably meaningless. (Of course its 
meaningful for BYE.)

> And it seems quite safe that if the REFER receives a 481 response, the
> INVITE usage must not be functional any more, since the far end of that
> usage has denied that it can act on the REFER.

IIRC, 5057 decided that each dialog usage must get its own 481 before it 
goes away. I don't think there are any cases where a single 481 response 
can make multiple usages go away.

So the important question is whether the REFER is part of the INVITE 
usage and so its 481 takes down the INVITE usage or not. That gets 
especially interesting if  the dialog already had both an INVITE usage 
and a SUBSCRIBE usage. Does it make sense that the refer take down the 
INVITE usage and leave up the SUBSCRIBE usage?

> Now it's possible that the REFER, if it is successful, is the first
> transaction of the subscription usage.  But I don't think that has any
> paradoxical consequences, as by hypothesis, the REFER succeeded.

Yeah, its already so weird, why not a little more weird?

Also, I think it has recently been clarified that the 200 of a SUBSCRIBE 
should not be considered to create a dialog - that its the NOTIFY that 
creates the dialog. If so, then I suppose the same should be true of REFER.

Bottom line: I can live with it either way, but think it should be 
documented one way or the other.

	Thanks,
	Paul
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip