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

[Paul Kyzivat <[e-mail]>]

What you say below is stated as *fact*. But the reason we are having 
this discussion is because its not entirely clear what the proper 
interpretation should be. So I will take your statements as being your 
*opinion* on the subject. Your opinion would be of more value if you 
gave the justifications for it.

More inline.


aayush bhatnagar wrote:
> REFER if placed within the scope of the existing dialog usage of
> INVITE will reuse its dialog usage, and create an implicit
> subscription for the refer event package at the recipient. However, if
> the recipient chooses to reject the in dialog REFER request, the
> communication established by the INVITE should not be affected. Such a
> rejection scenario implies that the call transfer failed..however the
> existing active call should not be torn down.

> REFER if sent outside the scope of any exisiting dialog will behave as
> a dialog creating request and will establish a subscription at the
> recipient as described above. This subscription is only used to notify
> the status of the sip session referral to the originator and is
> seperate from any other subscribe usage that may have existed at the
> recipient.
> 
> As far as accessing the referred resource is concerned...using the
> method parameter, it depends upon the business logic of the recipient
> of the REFER request. You may send a REFER to a conferencing server
> with a method INVITE to invite a user to join a conference. A method
> parameter with the value BYE would imply removal from the conference
> by the server and so on.

It has been observed before, that REFER is very weak in defining clearly 
what actions a particular REFER should elicit. Because it is unclear, 
your are right that some discretion on the part of the recipient is 
required. However that's a bad thing if the sender and receiver of the 
REFER don't agree on what the action should be.

If I send a REFER to a conference focus, I probably expect it send an 
invite to the URI I supply and include the resulting session as another 
participant in the conference. If the focus decided instead that I just 
wanted it play a message to the recipient and then hang up, then I would 
be displeased.

But that is a digression. My point in bringing up the method was that 
the method potentially may have nothing to do with the INVITE usage even 
when the REFER is sent within a dialog that has an INVITE usage. That is 
an argument for saying that the REFER is not part of the INVITE usage.

> I dont think you can include a SUBSCRIBE in the method parameter of
> the REFER request. You have no way of telling the event package usage
> of the subscription to the recipient, as the event header cannot be
> included in the REFER request. Moreover, you can never be sure whether
> the subscription usage is even applicable to the recipient or whether
> the recipient even supports it.

There was already a reply to this.

I think it is certainly possible to see how you could provide enough 
info to enable the recipient to generate a valid SUBSCRIBE request. It 
is indeed harder to imagine how you could expect the recipient to 
extract any value from the resulting subscription. But that is part of 
the magic of REFER that remains unresolved.

	Thanks,
	Paul

> aayush
> 
> On 3/24/09, Paul Kyzivat <[e-mail]> wrote:
>>
>> 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 [e-mail] for questions on current sip
>> Use [e-mail] for new developments on the application of sip
>>
>