I must say, I believe Christer, Keith, and I are all on exactly the same
page. Amazing! (I can't remember any other time for that.)
Alan says:
And as for the requirements being clear, I think they are,
but perhaps many people just can't get their heads around
them. Only use servers for rendezvous functionality, and
that's it. Period. What part of this isn't clear?
Actually I thought it was reasonably clear when I did my initial review.
(Aside from the issue of PSTN interconnect, which also seemed to be in
scope, using some other sort of server.) Its become less clear to me in
the subsequent discussion, especially based on some of the comments from
Eunsoo.
But what *wasn't* clear is what it is expected that these UAs will be
able to *do* when they have rendezvoused, using this set of specifications.
I might actually understand this better if it were billed as a "primer"
to the hitchhikers guide: a suggestion of what to learn first if you are
trying to get started as a sip implementor.
But rather it seems to be billed as "this should be all you need to
know", and it that case I really want to know "all I need to know to do
XYZ".
Thanks,
Paul
DRAGE, Keith (Keith) wrote:
Going to another organisation for a definition of profile (ETS 300 406
but I believe it is consistent with ISO 9646):
"A profile identifies a consistent set of chosen options from a base
specification or from a set of base
specifications, in order to provide a given function in a given
environment.
By restricting choices among the options available in the base
specifications, a profile increases the
probability that systems will interoperate, i.e. perform together the
given function to which the profile is
aimed at.
The base specifications upon which a profile is based are called
components of this profile."
What you have is a profile.
What needs to be clear is when that profile is useful to a reader, and
when it merely provides a chocolate teapot. Paul is saying that and I
agree with him. Noone is saying that the profile you have provided is
not useful.
Regards
Keith
-----Original Message-----
From: sipping-bounces@xxxxxxxx
[mailto:sipping-bounces@xxxxxxxx] On Behalf Of Alan Johnston
Sent: Wednesday, October 22, 2008 6:44 PM
To: Christer Holmberg
Cc: sipping@xxxxxxxx; Paul Kyzivat
Subject: Re: [RAI] Expert review of
draft-sinnreich-sip-tools-03
I've been holding off wading into this discussion to see
where it goes.
As it has really gone off track, I'll put in my views.
Firstly, this is *not* a profile of SIP - this document
doesn't say you don't have to support parts of RFC 3261.
However, it is, perhaps, a profile of the entire set of SIP
extensions. As such, it is a valuable counterweight to the
Hitchhikers guide which is a frightening expose of the
kitchen sink of extensions we have developed over the years.
And as for the requirements being clear, I think they are,
but perhaps many people just can't get their heads around
them. Only use servers for rendezvous functionality, and
that's it. Period. What part of this isn't clear? I know
it doesn't fit with the current service provider/research
focus that is what drives us today in RAI. And if this is
your focus, you can ignore the document and go back to your day job.
I think that many people will applaud and understand this
draft, but those people aren't the ones who post on the RAI
lists every day. They are the poor implementors who are
trying to get by and interoperate given the mess we have created.
Thanks,
Alan
Christer Holmberg wrote:
Hi,
I agree with Paul.
Normally, when you put together a list of RFCs etc that you
need to support/implement, you do that based on REQUIREMENTS.
The requirements may be specified for a typical network
architecture (IMS for example), and/or requirements specified
by a customer.
So, I think it should be clearly written what requirements
the spec is trying to solve (we do that with all SIP specs
nowadays, don't we?). If we're just trying to come up with a
good list of RFCs based on "taste", many people may have
different opinions on what it should contain...
In addition, in my opinon the draft defines a PROFILE.
Regards,
Christer
________________________________
From: sipping-bounces@xxxxxxxx on behalf of Paul Kyzivat
Sent: Wed 22/10/2008 16:52
To: Adrian Georgescu
Cc: sipping@xxxxxxxx
Subject: Re: [RAI] Expert review of
draft-sinnreich-sip-tools-03
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.
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.
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 SIP UA today (which I do actually) Henry's
draft would be the starting point. I would definitely add
MSRP to it,
without relays as a minimum but adding relay extension is not that
difficult, because any application that requires reliable or large
data transport need a TCP media plane that SIP signalling
or RTP does not provide.
End-to-end encryption can also be realized on top of
established MSRP
session. File transfer and session based IM are
applications that an
end user would take for granted today and SIP lacks both.
If I were to develop a UA today, I think I would figure out who I
intend it to connect to, and find out what their
requirements are. If
somebody already has made a consolidated set of requirements that
covers all those things I intend to talk to then that would
be helpful to me.
That is what I am lacking in the present document. It
doesn't tell me
what its field of applicability is.
Thanks,
Paul
Also the rich presence conflicts with the basic presence PIDF, I
would go for rich presence even if the "richness" of the
information
is something that would be avoided due to its complexity in the
presentation to end-user interface.
For the rest I would not do much changes to the draft.
Regards,
Adrian
>>>>>>>>
Henry,
Based on this discussion, it now sounds like you are
heading in *two*
directions:
- connecting to a SP that provides services (e.g. 911,
maybe others,
like voicemail, forwarding, ...)
The SP in this case is largely looking for a "dumb" device and
provides the services in the network. The "request for service"
is then "tunneled" via simple services like invite, with the
service request encoded in the AOR. (e.g. the "911", or
"star" codes).
In this case you are then competing with other profiles, such as
SIPConnect or PacketCable.
- very low added value SP, that simple provides registration
and routing. All services are provided by the UAs.
I'd like to see the goals spelled out better. Then we can
discuss if
they are met.
Thanks,
Paul
_______________________________________________
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
_______________________________________________
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
