Well there is a trade-off, of complexity vs. less number of messages required to negotiate a signaling mechanism for dtmf or mid-call signaling data exchange. In absence of a standard way of doing implementations have been using other mechanisms like INFO or unsolicited Notify, which works well within so called walled gardens. This whole thread started with a realization that INFO is not correct for such a mechanism. So either we agree and work out something which is standard or live with proprietary implementations.
Thanks. >-----Original Message----- >From: Eric Burger [mailto:[EMAIL PROTECTED] >Sent: Monday, October 22, 2007 6:57 PM >To: Paul Kyzivat (pkyzivat) >Cc: sip >Subject: Re: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO) > >Not *factors* of 2 or 4, but cyclomatic complexity increasing >by a *count* of 2 or 4. > >However, the result is similar: there is tons of Software >Engineering data that shows when modules get above a >cyclomatic comlexity of 7, the number of latent defects raises >non-linearly. > >Henning (or some lurker looking for something to do): an >interesting Master's Thesis would be to calculate the >theoretical minimum cyclomatic complexity of the current SIP >state machine. That may answer the, "Why SIP does not >interoperate" question. > > >On 10/22/07 3:30 PM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote: > >> Eric, >> >> I disagree with your *quantitative* assessments of how much thee >> things increase complexity (by factors of 2 or 4). But I certainly >> agree that complexity *will* increase. >> >> In the end everything we are doing increases complexity, so maybe we >> should all pack up shop and go home. >> >> Ultimately this all comes down to deciding how complex >things have to >> get before people can do what they think they need to do. >> >> Paul >> >> Eric Burger wrote: >>> >>> >>> On 10/17/07 2:18 PM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote: >>> [snip] >>>> One agreed upon, NOTIFY may be sent in the agreed upon >direction(s) >>>> within the INVITE dialog usage. Whether an initial NOTIFY is >>>> required will be determined on a per-event-package basis. (Its not >>>> needed to establish the dialog, so its a matter if it is >>>> semantically needed in the context of the event type.) >>> >>> Which is not the way NOTIFY works today, which means the sender has >>> to have code to the effect: >>> >>> if( !real_notify(event_object) ) >>> { >>> if( needs_first_notify(event_object) ) >>> { >>> send_event(event_object); >>> } >>> } >>> else >>> send_event(event_object); >>> >>> Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised >>> the complexity of your notification stack by 2. >>> >>> [snip] >>> >>>> There is no separate subscription or timer. The dialog usage is >>>> refreshed by INVITE or UPDATE in the conventional manner. >Events to >>>> be exchanged are renegotiated from scratch with every >reINVITE or UPDATE. >>> >>> So what does the NOTIFY put into expires? I hear hk now: >"Just stuff >>> it with 99999." OK, this now adds another hack into send_event(), >>> "If I am a real SUBSCRIPTION, return the timer; if I am not, return >>> 99999." Just upped the complexity by 1. >>> >>> Worse yet, what does the recipient do when it gets a BYE? >Now it has >>> either a resource leak or more code: >>> >>> if( got_bye(dialog_object) ) >>> { >>> for each pseudo-dialog subscription in the (dialog_object) >>> { >>> consider the subscription terminated; >>> } >>> } >>> >>> Upping the complexity by 2, again. >>> >>> Hey - we are not done yet! I will leave as an exercise to >the reader >>> the amount of complexity added to create the implicit >subscription in >>> the first place. >>> >>> I forgot, this really is targeted for devices that will hard code >>> everything and not support any real SUBSCRIBE/NOTIFY packages. >>> [facetious] >>> >>> It would be much cleaner to call this thing "NOTQUITENOTIFY". >>> >>> Of course, since we are anal about messages and bandwidth, >let's save >>> 300ns and just call the method "I". [joking] >>> >>> [snip] >>> >>> >>> 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. >>> >> > > > >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 > _______________________________________________ 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
