Re: Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO)
Paul Kyzivat <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
aayush bhatnagar wrote: >>Go read 5057. The usages are to be handled separately. So this should > *not* provoke the UAC >to clean up its INVITE dialog usage. > > I have read the relevant RFC. From 5057: OK, sorry. It just sounded like you might not have. > -Existing implementations that destroy all other usages in the dialog > will continue to function as -they do now, except that peers following > the recommendation will attempt to do things with the -other usages and > this element will return 481s for each of them until they are all gone. > > I think it is more feasible to destroy the entire dialog, than keeping > on to 'hung' state until all the dialog usages are all gone as suggested > above. I am familiar with implementations that clean up dialog state > when they get a 481-dialog does not exist response, even if there were > other 'active' usages of that dialog. I'm not surprised. Its often "more feasible" to do the wrong thing than the right thing. But that doesn't make it right. While its not written in black and white in 3261, there is enough info there to infer that you need to treat them separately. > The reason being, that if an implementation cannot find a matching > dialog as characterized by the local tag, remote tag, call-id, local and > remote sequence nos etc and has rejected the request by a 481, there is > no point in keeping the dialog state at the UAC. This is all hashed out in 5057. The problem is that the 481 response is *ambiguous*. The way to maximize interop is to treat the 481 as meaning the least serious thing that it could mean - that only the usage has gone away. If it turns out that the whole dialog went away, then you will eventually find that out anyway. Of course it doesn't hurt to treat it as meaning all the usages went away if you would not continue all of them anyway. But if the other usage(s) continue to be of value then it you are hurting yourself by assuming they have gone away when they might not have. > As for example, if you receive a 481 response for a REFER sent within > the INVITE dialog, there is no point in keeping the REFER usage alive. > You probably sent the REFER to transfer a call, which the server > complains that the call itself does not exist (481). That's not the case of relevance. If you got a 481 for a REFER, the refer of course failed, and so there is no refer usage to keep alive. We are still, in this thread, trying to decide what a 481 to a REFER means. I think it won't be ambiguous - that it can *only* mean that the whole dialog is gone, since it is never associated with a preexisting usage. Even so, you would be well advised to probe any existing usages with in-usage messages to verify if they are alive, even though most likely they are not. > Moreover from 5057: > > -Processing multiple usages correctly is not completely understood. > -What is understood is difficult to implement and is very likely to > -lead to interoperability problems. The best way to avoid the trouble > -that comes with such complexity is to avoid it altogether. > -When designing new applications or features that use SIP dialogs, do > -not require endpoints to construct multiple usages to participate in > -the application or use the feature. > > This is very true. By defining multiple dialog usages, you are > essentially extending the dialog state (as defined by 3261) by adding > more attributes to it (such as subscription duration etc). I cant think > of a practical use case, where a subscription that shared the invite > dialog usage still needed to be preserved, even when the original INVITE > dialog was no longer active. We aren't *adding more attributes to it*. It is what it is and has been. It has been implicitly legal in spite of the problems. And it *is* used. There are even reasonable use cases for independent termination of the usages. For instance, a refer usage sharing a dialog with an invite usage may meaningfully survive after the invite usage terminates. > As for example a subscription to the 'conference' event package sent > within the scope of an INVITE dialog. If i leave the conference by > sending a BYE, and my subscription's duration is still valid for an > hour...will i still keep on getting redundant SIP notifications for > changes to the membership to that conference ? > In the sense of 5057, the > subscribe usage will be preserved until it expires, or until the UAC > explicitly un-subscribes, or the conference server has to send me a > final NOTIFY with my subsription-state = terminated. IMO that is exactly as it *should* be. If the subscriber doesn't want to maintain the subscription, it can simply wipe out the state of the subscription. Then when another NOTIFY is received, a 481 will be sent because there is no state, forcing the end of the usage. But *assuming* that the subscription *should* go away when the invite ends is, IMO, wrong. There may be valid reasons to retain the subscription. > It is not important that 5057 is allowing us many theoretical > possibilities by presenting multiple dialog usages. > > What is more important is what extra do we get by reusing a dialog, and > how do implementations leverage upon such a possibility and create > meaningful applications around it ? > > I would like to share some examples: > > 1. As for example an application that can practically leverage upon 5057 > may send a SUBSCRIBE to the 'dialog' event package (rfc 4235) that > reuses the INVITE dialog can be used for creating SIP call tracing > applications. > > 2. Other Implementations may include automatic callback applications by > this mechanism (ring back when my sip phone is idle) etc. > > 3. Yet another application may send me by pre-paid account balance after > i disconnect my ongoing dialog, as it is subscribed to my dialog state. > > In all these example applications, the endpoint receiving the SUBSCRIBE > will need to send a NOTIFY that re-uses its existing INVITE dialog > (NOTIFY acting as a target refresh in the sense of 5057). Sounds like you are in favor of dialog reuse. Paul > Best Regards > > aayush > > > On Wed, Mar 25, 2009 at 7:36 PM, Paul Kyzivat <[email protected] > <mailto:[email protected]>> wrote: > > > > aayush bhatnagar wrote: > > If you send an in dialog request (REFER in our case), then you > cannot > decouple its semantics with the existing dialog usage. > > > You say "*the* dialog usage" as if there can be only one. There > could be more than one. It might be coupled to: > - the *only* existing usage > - to *one* of several existing usages > - to *none* of the one or more existing usages > > For instance, I could have a dialog with just an INVITE usage (the > common case) and within that dialog send a REFER of a MESSAGE. That > MESSAGE really has nothing to do with the INVITE usage. > > > So saying that > even if i send a REFER within an existing dialog, and still decouple > it from the existing dialog usage will not be possible. > If there were such a requirement, then REFER should have been > sent as > a standalone dialog creating request outside the INVITE usage. > > > One can argue that it *should* have been. But that isn't the point > of this discussion. In many cases using the same dialog as been an > expedient to ensure reaching the same UA when you aren't sure the > remote target url for the dialog is in fact routable. > > > The recipient of the in dialog REFER will treat it like it > should any > in dialog request. It has no way to decide if this request > potentially > had nothing to do with the existing dialog usage. > > > You are being sloppy in your use of "dialog" and "dialog usage", as > if you are not familiar with RFC 5057. If you aren't, please read it. > > > i agree with you when you say that an indialog refer receiving a 481 > would mean that the INVITE dialog has been torn down. > > > See my reply to Dale. > > > However, a refer dialog usage can also terminate, if the UAC sends a > 481 in response to the NOTIFY sent by the UAS (Suppose the > transaction > did not match). > > > You need to spell out more details of the case. If it were the > *first* NOTIFY, resulting from an in-dialog REFER, then that > response would be indicative of a screwup somewhere. > > However, if there had been a prior NOTIFY on the refer subscription > that indicated that the subscription was over, and then somehow > *another* NOTIFY was sent, the 481 would be appropriate, indicating > that the refer-usage was no longer present. > > > This scenario may happen irrespective of whether the > REFER was within the invite usage or created its own distinct > dialog. > If this happens when REFER was sent within an Invite dialog, > then the > UAC will be mistaken to clean up its INVITE dialog state. > > > Go read 5057. The usages are to be handled separately. So this > should *not* provoke the UAC to clean up its INVITE dialog usage. > > > I did not understand one part in the paradox above when you said... > "A REFER within an established dialog having no invite usage to be > considered as an out of dialog REFER" > Do you mean to imply a REFER in some other Subscribe event package > dialog for example? > > > Yes, that is what I meant. I don't have any meaningful cases in > mind, but it is a theoretical possibility. > > Paul > > > aayush. > > On 3/25/09, Dale Worley <[email protected] > <mailto:[email protected]>> wrote: > > On Mon, 2009-03-23 at 21:32 -0400, Paul Kyzivat wrote: > > 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. > > That's a nice pathological case. But within the context of > the current > 5 possible meanings of REFER, it seems to be most parallel > to the > out-of-dialog REFER. > > 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.) > > A fascinating possibility! But I'm not sure that we've ever > defined how > a REFER within a simple INVITE dialog, specifying a > non-INVITE method > should act. So there's no analog to follow. > > 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? > > I think we're a victim of sloppy terminology here. If I > send a REFER, > and the far end responds 481, then clearly the far end knows > of no > INVITE usage, or otherwise it would not have responded 481. > So I should > delete my belief that there is an INVITE usage. Whether we > consider the > REFER in question to be "part of" the INVITE usage or not > doesn't change > anything -- the 481 is evidence that the far end has no > knowledge of the > usage. > > However, we do have this fine paradox: If we assume that a > REFER within > an established dialog that has no INVITE usage is to be > treated as an > out-of-dialog REFER, then *no* REFER will receive a 481 > response! > Indeed, if I send a REFER thinking that there is an active > INVITE usage, > but the far end believes the INVITE usage has ended, will > cause the far > end to do something (initiate an independent dialog) that is > considerably different from what I expected (transfer the > current INVITE > usage). > > Dale > > > _______________________________________________ > 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