Subject: RE: [Sip] Why not ISUP?

From: Matt Holdrege <[email-masked]>
Date: Thu, 06 Sep 2001 22:01:00 -0700

At 08:34 PM 9/6/2001, Nathan Nelson wrote:
>ISUP is a traditionally ridge protocol that has limit capacity to adapt to
>changes.  Each time a new feature is added it takes 18 months of debate, 18
>months of development, and then you get Calling Name Delivered.  If it does
>not work in SIP send an email and next month you have an RFC.  If people
>like it they develop to it, if not next month you have a new RFC.

I don't know whether to laugh or cry. If it were that easy to create an RFC 
we would have chaos. In reality, as SIP is further deployed, making changes 
to the core protocol will likely be much more difficult than updating ISUP.

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Sep 2001 08:50:09 -0400

The whole idea is *not* to make changes to the core protocol. Leave the
core protocol generic and application-agnostic, and add extensions that
only affect people that are interested in the particular feature.
Examples include, so far, the event model, reliable provisional,
manyfolks, refresh and a few others - if you don't care about these
features or they don't apply to your environment, you can blissfully
ignore them. This does cause us some pain now, as we have to avoid the
usual "design feature X into the protocol" trap, but yet allow enough
tools. The extension mechanisms and the now-emerging cleaned-up
generalized routing mechanism allow for this. (With hindsight, a
generalized reliability mechanism that avoided the 100rel and INVITE
special cases would have been nice, too, but that's hard to backfit.)