I am in favor of dialog reuse as long as i can achieve something by it practically. Coming from the IMS world, i am always on the lookout for creating interesting sip apps around new concepts.
This RFC, i think also imposes certain functionality on the sip client (clients being in a very sorry state in IMS). aayush On 3/25/09, Paul Kyzivat <[email protected]> wrote: > > > 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
