> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Paul Kyzivat > Sent: Monday, March 23, 2009 6:33 PM > To: Dale Worley > Cc: SIP IETF; Brett Tate > Subject: Re: [Sip] Is REFER within dialog part of INVITE or > subscription usage? (was RE: SIP INFO) > > > > 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
Yes, I think so. > 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. Consider a third party control application that forces an endpoint to register : REFER sip:phone.doken.com SIP/2.0 Refer-To: <sip:[email protected];method=REGISTER> that triggers a REG to the registrar as : REGISTER sip:[email protected] SIP/2.0 > > 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
