[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03
Yes, I was aware that you were going make that clear in the
specification. I was just using that RFC number as an example of the
impact of either inclusion or no inclusion - thus demonstrating a more
general point.
Regards
Keith
> -----Original Message-----
> From: Henry Sinnreich [mailto:hsinnrei at adobe.com]
> Sent: Wednesday, October 22, 2008 10:13 PM
> To: DRAGE, Keith (Keith); sipping at ietf.org
> Subject: Re: [Sipping] [RAI] Expert review of
> draft-sinnreich-sip-tools-03
>
> Keith,
>
> Sorry to repeat: The SIP UA can call any emergency SIP URI
> such as SOS or dial 911 through a PSTN gateway. Is this clear enough?
>
> Needless to point out that using the Internet for emergency
> and avoiding 911 will also support life saving data such as
> medical vital signs, location (GPS & mobile triangulation) and video.
>
> Henry
>
>
> On 10/22/08 11:45 AM, "DRAGE, Keith (Keith)"
> <drage at alcatel-lucent.com>
> wrote:
>
> > 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
>
>
_______________________________________________
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