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

[Paul Kyzivat <pkyzivat at cisco.com>]

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