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

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