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@xxxxxxxxx] > Sent: Wednesday, October 22, 2008 10:13 PM > To: DRAGE, Keith (Keith); sipping@xxxxxxxx > Subject: Re: [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@xxxxxxxxxxxxxxxxxx> > 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@xxxxxxxx > >> [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Adrian Georgescu > >> Sent: Wednesday, October 22, 2008 10:43 AM > >> To: sipping@xxxxxxxx > >> Subject: [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@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
