[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
> aayush bhatnagar
> Sent: Monday, March 23, 2009 8:30 PM
> To: Paul Kyzivat
> Cc: SIP IETF; Brett Tate
> Subject: Re: [Sip] Is REFER within dialog part of INVITE or
> subscription usage? (was RE: SIP INFO)
> 
> 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.

One can send a out of dialog, norefersub REFER and no dialog is established at the recipient. Only an implicit subscription is created and a NTFY may be sent or not sent at all.

> 
> 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.
> 
> 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

It should be possible to do Refer-To: sip:serhad at doken.com;method=SUBSCRIBE?Event=presence asking REFER receiver to send me a SUBSCRIBE in order to find out about my presence.

> 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.
> 
> aayush
> 
> On 3/24/09, Paul Kyzivat <pkyzivat at cisco.com> 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 sip-implementors at cs.columbia.edu for questions on current sip
> > Use sipping at ietf.org for new developments on the application of sip
> >
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip