Dialog termination is where I see the most potential for confusion. I would also offer these problems are not insurmountable. However, I would be curious to find out if solving these problems does not reconstruct RFC 3265 in its full glory.
Let us take two scenarios for the easy case of transporting user stimulus. In the first case, the user presses a button and hangs up. Because of normal Internet routing, the INFO (Invite-based Notification Function Output ;-) message arrives after the BYE arrives. What to do? What if the button pressed was "don't launch missiles?" In the second case, the application is using digit maps, because the application developer realizes that 1100 bytes of SIP headers to transport one byte of user stimulus information is stupid. The device buffers some digits, but the user hangs up. What does the endpoint do? Does it send the collected digits? Does it eat the collected digits? Any argument other than an explicit negotiation (like KPML does) is not going to work in the general case. This is because if we say, for DTMF, "always send buffered digits," then what we are really saying is, "always send what you have before the dialog terminates." I could easily envision packages that would have tons of state that is immediately irrelevant at dialog termination. Dumping tons of bytes on the network again totally defeats the "We want this because it is lightweight" argument. On 10/14/07 5:35 PM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote: > > > Christer Holmberg wrote: > >> I haven't thought about this proposal in detail yet, but we would also >> need to take the the dialog-reuse spec (which proposes NOT to mix dialog >> usages) into consideration. But, if we somehow could bind the >> subscription lifetime to the dialog lifetime I think that at least some >> of the issues in that spec would be solved. > > The lifetime of a dialog isn't an independent variable - it ends when > the last dialog usage ends. > > If you are really talking about implicit *subscriptions*, then you > either must explicitly end them, or else define their *implicit* end in > terms of something that has an explicit endpoint. > > I expect that you are talking about something that either shares the > invite dialog usage, or else a distinct dialog usage that implicitly > starts and stops concurrently with the invite dialog usage. > > Paul Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.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
