Hi, >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. I agree. It's a high level profile. In order to ensure interoperability you would need to go more into the details, talking about what parts of the listed RFCs need to be supported, and HOW they need to be supported (use-cases etc). >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. Fair enough, but then that should be clearly indicated in the beginning of the draft. >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. Eventhough the document may not fit into the architectures I am working on, my general opinion is that profiles are important indegrients for interoperability (as I also indicated at the SIPForum workshop in Chicago). And, even if you only use servers for rendezvoud functionality, I still think there are a number of additional drafts which would "qualify". I am also sure there are other media security mechanisms that the one you have listed which would fit. BUT, if the purpose of this document is to simply say "Hey, this is what we have done", then fine - then you don't need any further requirements. >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. I have never said I don't like the draft. I think it's a good initiative, which I have also told Henry off-line. But, based on experience I know that it is always helpful to know exactly what the intention of a draft is - and make sure that others also know it. Regards, Christer 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
