[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03
> 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 IntFrom sipping-bounces at ietf.org Wed Oct 22 14:04:25 2008
Return-Path: <sipping-bounces at ietf.org>
X-Original-To: sipping-web-archive at optimus.ietf.org
Delivered-To: ietfarch-sipping-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id B56B33A6A83;
Wed, 22 Oct 2008 14:04:25 -0700 (PDT)
X-Original-To: sipping at core3.amsl.com
Delivered-To: sipping at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id EEE643A6B35
for <sipping at core3.amsl.com>; Wed, 22 Oct 2008 14:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.228
X-Spam-Level:
X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.371,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Mayfnr7CHHcB for <sipping at core3.amsl.com>;
Wed, 22 Oct 2008 14:04:17 -0700 (PDT)
Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25])
by core3.amsl.com (Postfix) with ESMTP id 5D0B93A6A83
for <sipping at ietf.org>; Wed, 22 Oct 2008 14:04:16 -0700 (PDT)
Received: from source ([192.150.8.22]) by exprod6ob110.postini.com
([64.18.5.12]) with SMTP; Wed, 22 Oct 2008 14:05:15 PDT
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51])
by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id
m9ML5CE0018290; Wed, 22 Oct 2008 14:05:13 -0700 (PDT)
Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70])
by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id
m9ML5Biq005311; Wed, 22 Oct 2008 14:05:12 -0700 (PDT)
Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com
with Microsoft SMTPSVC(6.0.3790.1830);
Wed, 22 Oct 2008 14:05:11 -0700
Received: from 10.7.242.142 ([10.7.242.142]) by namail5.corp.adobe.com
([10.8.192.88]) with Microsoft Exchange Server HTTP-DAV ;
Wed, 22 Oct 2008 21:05:11 +0000
User-Agent: Microsoft-Entourage/12.12.0.080729
Date: Wed, 22 Oct 2008 16:05:09 -0500
From: Henry Sinnreich <hsinnrei at adobe.com>
To: Paul Kyzivat <pkyzivat at cisco.com>, Adrian Georgescu <ag at ag-projects.com>
Message-ID: <C524FFB5.9330%hsinnrei at adobe.com>
Thread-Topic: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03
Thread-Index: Ack0id2dI9r1q3JcoUG1MfvoFXY1OQ==
In-Reply-To: <48FF738D.30504 at cisco.com>
Mime-version: 1.0
X-OriginalArrivalTime: 22 Oct 2008 21:05:11.0893 (UTC)
FILETIME=[DF56A050:01C93489]
Cc: sipping at ietf.org
Subject: Re: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03
X-BeenThere: sipping at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>,
<mailto:sipping-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sipping>
List-Post: <mailto:sipping at ietf.org>
List-Help: <mailto:sipping-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>,
<mailto:sipping-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sipping-bounces at ietf.org
Errors-To: sipping-bounces at ietf.org
> 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 at cisco.com> 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 at cs.columbia.edu for questions on current sip
>> Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
> Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP
ernet 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 at cisco.com> 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 at cs.columbia.edu for questions on current sip
>> Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
> Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP