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:abhatnagar192006 at gmail.com]
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.
>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.
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 <sdoken at qualcomm.com> wrote:
> 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
|