[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 at ietf.org [mailto:sipping-bounces at ietf.org] On Behalf Of Alan Johnston 
Sent: Wednesday, October 22, 2008 6:44 PM
To: Christer Holmberg
Cc: sipping at ietf.org; Paul Kyzivat
Subject: Re: [Sipping] [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 at ietf.org on behalf of Paul Kyzivat
Sent: Wed 22/10/2008 16:52
To: Adrian Georgescu
Cc: sipping at ietf.org
Subject: Re: [Sipping] [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 at cs.columbia.edu for questions on current sip Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP