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