Re: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03

[Paul Kyzivat <[e-mail]>]

Henry Sinnreich wrote:
>> 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.

Leave the legacy telephony things out of it. Is this intended to define 
a *new* "walled garden" of things that can talk to one another using 
this set of specs but perhaps not to other things? Is it expected to 
interoperate with devices that implemented 2543, or some other subset of 
the specs you call out?

What about devices that implement richer, but different sets of sip 
specs? Somebody might implement IM using MSRP, and not be able to 
interoperate with a device following sip-toos recommendatations because 
that uses MESSAGE. Since there is currently no requirement that those 
implementing MSRP also implement MESSAGE, this could be a problem even 
among devices that support "IM".

> 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.

Its one thing to define this bounded world so that it excludes PSTN. 
There are certainly valid use cases for that.

Its another thing if you then intend to open it up to the PSTN via 
gateways. Then, to get any interop you will get all tied up in knots 
about how phone numbers are encoded as URLs, etc.

> 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,

I'm certain we have many flavors of legacy SIP. But I think I would 
leave that terminology for sip usages that were considered appropriate 
in the past, but that are no longer considered appropriate. For 
instance, 2543 implementations and some uses of INFO. Some past attempts 
to use MESSAGE for IM sessions might also fall into that category. (But 
they may better be simply considered proprietary.)

I take your point about attempts to replicate the PSTN via SIP, but I 
think that deserves some other sort of name. Some of that is *bad* and 
some of it is *good*. And if you get 10 people together to discuss it I 
expect you will get at least 20 different opinions of which parts are 
good and which are bad.

The fact that you mention PSTN gateways as perhaps fitting into systems 
based on these sip-tools suggests to me that you think communicating 
with the PSTN via sip isn't all bad. For better or worse, there are 
billions of devices out there that can be reached that way and no other.

So then it becomes a matter of where you draw the line. Do you want a 
device that is implemented via sip-tools specs to be able to have a 
phone number as its AOR, and be reached from those billions of PSTN 
devices? Many will consider that to be a desirable thing. But it seems 
to come with a bunch of regulatory strings attached.

> 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)?

I'm sure there are interesting possibilities there, but they need to be 
specified if they are to be interoperable.

IMO the most basic "network" feature after rendezvous is for something 
useful to happen if there is no registered device to rendezvous with. 
Voicemail is one possibility, forwarding, redirecting are others. The 
possibilities are endless. One of my favorite concepts is for the home 
proxy to return a 3xx with an html or mail URL if there are no sip 
contacts registered. But that isn't useful unless the callers are 
prepared to do something meaningful when they get such a response. 
(E.g., locally record a voice/video message and email it to the returned 
mail address.)

In *theory* such behavior is covered by a UA that implements to 
sip-tools. But in practice there needs to be something that describes 
that behavior.

	Thanks,
	Paul

> But this is for another day. Let's enjoy simple SIP for now.
> 
> Henry
> 
> On 10/22/08 1:40 PM, "Paul Kyzivat" <[e-mail]> 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 [e-mail] for questions on current sip
>>> Use [e-mail] 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 [e-mail] for questions on current sip
>> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP