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