Re: [Sipping] [RAI] Expert review of draft-sinnreich-sip-tools-03

["DRAGE, Keith \(Keith\)" <[e-mail]>]

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:[e-mail]] 
> Sent: Wednesday, October 22, 2008 10:13 PM
> To: DRAGE, Keith (Keith); [e-mail]
> 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)" 
> <[e-mail]>
> 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: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Adrian Georgescu
> >> Sent: Wednesday, October 22, 2008 10:43 AM
> >> To: [e-mail]
> >> 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 
> >> [e-mail] for questions on current sip Use 
> >> [e-mail] 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 
> > [e-mail] for questions on current sip Use 
> > [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP