Perhaps presence was not the best example there given what is supported today though that should not limit the imagination since new services/devices pop up every day. Point is this can be enabled by the basic Sip building blocks.
Event=kpml will do for a use case that an endpoint tells the server that it wants the key presses to be monitored. I was making the case that SUB can be included in method parm of REFER. Serhad From: aayush bhatnagar [mailto:[email protected]] Sent: Tuesday, March 24, 2009 1:19 AM To: Doken, Serhad Cc: Paul Kyzivat; SIP IETF; Brett Tate Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO) >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]<mailto: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]<mailto:[email protected]>> wrote: > -----Original Message----- > From: [email protected]<mailto:[email protected]> > [mailto:[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]<mailto: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]<mailto:[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]<mailto:[email protected]> > > for questions on current sip > > Use [email protected]<mailto:[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]<mailto:[email protected]> > for questions on current sip > Use [email protected]<mailto:[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
