>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. you are right.
>It should be possible to do Refer-To: >sip:[email protected]<sip%[email protected]>;method=SUBSCRIBE?>Event=presence asking REFER receiver to send me a SUBSCRIBE in order to find out about >my presence. In case the receiver is a server in the network, it must implement the role of a PNA. If its an endpoint, it will subscribe only after approval of the human user, else respond back with 400. I am not sure how many presence clients support forced subscriptions like this. On Tue, Mar 24, 2009 at 1:01 PM, Doken, Serhad <[email protected]> wrote: > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] 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:[email protected]<sip%[email protected]>;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 <[email protected]> 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 [email protected] for questions on current sip > > > Use [email protected] 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 [email protected] for questions on current sip > > Use [email protected] 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 [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
