> But as long as > there is the possibility that you might have to interact with somebody > that only implemented the old way, This is another good point that I believe we have to write down. Simple SIP is not meant to interoperate with all the telephony features for which 100 flavors of SS7 have been deployed (there were ~100 the last time I looked). RFC4485 states very clearly SIP is not a replacement for the PSTN. If you don't agree with RFC4485 "Guidelines for SIP Authors" just say so. Our simple SIP is rather the KISS Internet approach. It seemed to us the section of what is out of scope was clear enough, but this discussion is helpful. The authors have stated clearly the main usage scenario for the simple SIP _alternative_ is for SIP as a Rich Internet Application and also for P2P SIP where everything is in the endpoints. Finally, SIP can re-join the web! (That's where it started around 1996 and what made it successful IMO). This does not preclude a few simple servers such as voice mail. But as you Paul have pointed out, interoperability with the PSTN is left to SIP-PSTN gateways. This was the other good point you made. Also, to preclude any misunderstandings, simple SIP is out of scope for all the SIP extensions meant to contradict the spirit of RFC 4485. "Legacy SIP" (yes we have arrived here) that is intended to emulate the PSTN, private extensions to accommodate various business models is also out of scope. As mentioned, we aim to use SIP just as a a reasonably simple _Internet_ protocol, working best in the e2e (different from p2p) model and simple CS model for rendezvous and maybe some other plain functions such as voice mail storage. Now thinking about voice mail, why not place it in some cloud computing? Why does one need dedicated feature servers and not move the features into the cloud, if you don't like the endpoints (SIP UA)? But this is for another day. Let's enjoy simple SIP for now. Henry On 10/22/08 1:40 PM, "Paul Kyzivat" <pkyzivat@xxxxxxxxx> wrote: > > > Adrian Georgescu wrote: >> >> On Oct 22, 2008, at 6:30 PM, Paul Kyzivat wrote: >> >>> Most who have worked on sip for awhile would probably agree that if we >>> could start over with a clean slate and all that we now know we could >>> create something simpler and better. But there is too much investment >>> in implementations of what we have, making a clean slate infeasible. >>> We are stuck with what we can do in an evolutionary way. >> >> I wish we do not have to be stuck in the infinite complexity created by >> our past mistakes. Unless you are talking about some terminal desease or >> the like you can always fix a bad decision your took in the past with a >> good decision you take now. > > Yes and no. You can always create a new way to do something that is > better than the old way, rendering the old way obsolete. But as long as > there is the possibility that you might have to interact with somebody > that only implemented the old way, you have to be prepared for that > eventuality. Hence the complexity just goes up. > > A bunch of people spent several years defining SDPng - a replacement for > SDP that intended to remedy all of its limitations. Eventually the whole > effort was dropped, largely (IMO) because the pain of migrating to it > exceeded the benefit of doing so. > > Thanks, > Paul > >> Or to quote from a book I read "Any mistakes you commit through >> audacity are easily corrected with more audacity". Don't know who wrote >> this. >> >> Adrian >> >> _______________________________________________ >> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip >> Use sip@xxxxxxxx for new developments of core SIP >> > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
