[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03
I believe most of us are actually on the same page which is:
- if you consider a feature is necessary (for this profile) then
list all the documents needed to support that feature.
- if a feature is not necessary (for this profile) then clearly
say that the set of documents identified will not support that feature.
Thus I seized on RFC 3966 earlier. Using that as an example, I have no
problem with the profile either including it or not, but if it is not
there, then clearly say that interworking with the PSTN will not be
possible, and that emergency calls using PSTN like numbers will be
impossible.
Obviously various network providers will have their reasons for various
extensions being necessary and supported in their networks. Readers need
to be able to clearly identify the mismatch between what the profile
contains and what those operators think is needed. What those network
providers would call "plain SIP" would not be the same list as you would
use. The security requirements invariably differ.
Regards
Keith
> -----Original Message-----
> From: sipping-bounces at ietf.org
> [mailto:sipping-bounces at ietf.org] On Behalf Of Adrian Georgescu
> Sent: Wednesday, October 22, 2008 10:43 AM
> To: sipping at ietf.org
> Subject: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03
>
> 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.
>
> 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.
>
> 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