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
