[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
> 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:serhad at doken.com;method=REGISTER>

that triggers a REG to the registrar as :

REGISTER sip:serhad at doken.com 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip