[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03
Thanks Paul
Now I understand why SIP became so complicated.
I am glad Henry could make it simple enough for me to get started :-)
Adrian
On Oct 22, 2008, at 6:30 PM, Paul Kyzivat wrote:
Adrian Georgescu wrote:
On Oct 22, 2008, at 4:52 PM, Paul Kyzivat wrote:
Adrian Georgescu wrote:
Hi Paul,
I believe Henry is heading into one direction only. The idea is
to help developers implement the minimum necessary features in
their User Agent and not biased towards a voice only application.
The SIP end-points as describe by Henry would work with any
service provider as long as they talk plain SIP. So 911 and
voicemail and other services can be performed in the network as
well, they are just another end-point.
There is a huge difference between services implemented in the UA
and services implemented in the network. Take for example
emergency services. The typical implementation is simply for the
UA to accept the dial string (e.g. 911) and put it into an INVITE.
The UA most likely is treating this as any other call - not
realizing it is an emergency call.
I can easily make the SIP UA give more priority and to that call
rather than re-engineering the whole Internet to do something like
that, can't I?
You can if you know which dial strings correspond to emergency
services. But if you are defining a generic device to be deployed in
a variety of places, with differing SPs, then how do you know that.
You then start to create ambiguity about where the service is
implemented - its part in the UA and part in the service. While that
may be an appropriate thing to do, it further complicates the
specification.
Hence it doesn't apply special processing to it, that is supposed
to be supplied, like refusing to disconnect the call on hangup.
Also, it doesn't play any part in determining its location -
depending on the network to be able to figure that out. The
network may or may not be able to determine that.
Do you mean a network can better figure out where I am rather than
myself? I highly doubt that I wish to let the network dispatch the
ambulance to where they think I am rather than where I am actually
(by my local GPS or AGPS device). Is up to me to convey location
information and not to the network.
I mean that in this scenario it is the SP that has taken the
responsibility.
If you want to do that (a good thing if you are able) then you need
to implement all the specs related to that (which aren't a part of
this list currently). And you need to be connected to the network in
such a way that you can actually talk to the PSAP, or work
cooperatively with the SP to do so.
The point is that the current list of specs don't support that.
In any case, each SP has its own requirements for what a device
that connects to it must do to work with it. Perhaps it would be a
useful thing to create a common spec for a UA that can work with
"most" SPs. To do that it would probably be better to gather the
specs from the SPs than to look at a few phone adapters. But I
think a lot of SPs are not open to connection from devices they
don't supply, so there may not be a lot of value in such a spec.
If I were to develop a UA today, I think I would figure out who I
intend it to connect to,
A SIP URI is a SIP URI. Do you make a distinction when you send an
email what type of server software or type of recipient is behind
the destination email address? Your email client works the same
every time. This is why you use email and skype today instead of
SIP. They do not make this distinction.
Why is this tendency with SIP to make it more complicated than it
actually is?
Certainly that is the ideal. We just aren't there yet.
The complexity is there because some people found a need for some
functionality. Some of that in retrospect was a bad idea. Other
things are indeed important to some people/environments but not so
important to others.
The authors of this draft assert that a much smaller set of specs is
"sufficient". But it won't be sufficient when interacting with
somebody that requires one of the other specs. That's why it is
still important to know your peer requires.
Is not a personal question, I am just wondering because I am young
and I was not around when SIP was invented.
Like many things, sip started out "simple". But it was found to be
insufficient in the simple form, so it was "fixed", and in the
process became more complicated.
In some cases this complexity is unavoidable - the earlier
simplicity was an illusion - sweeping things under the rug.
In other cases, the complexity is the result of evolution and the
need for backward compatibility. And in some cases its just that
things just weren't done as well as they might have been.
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.
Thanks,
Paul
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