Subject: RE: [Sipping] I-D ACTION:draft-watson-sipping-req-history-00.txt

From: "Cullen Jennings" <[email-masked]>
Date: Thu, 28 Feb 2002 22:45:25 -0800

I half way think I am going to regret trying to answer the all the use bases
but to take an honest stab at your question... There have been many use
cases that have come up at various times but a few are:

Imagine I called A who had forwarded their phone to B who did not answer and
it goes to voice mail.  These requirements could help the voice mail have
enough information to apply local policy to figure out what email box and
message should be played.

Imagine A calls my cell phone and I don't answer and they leave me a message
and hangup. A then calls my work phone and this rings three times then gets
forwards to my cell phone. It might be nice that A could get notified that
they have been forwarded to my cell phone so they can hang up and not wait
for it to ring since they know they just called it.

Imagine A called Proxy B which sequential forked to Set B which after 3
seconds sent a 302 to Set C which after three seconds sent a 302 to Set D
which after 3 seconds sent a 302 sending the call to proxy C which, with
lack of any better information is going to go through the Set B, Set C
sequence again before it tries Set D.

Imagine your favorite application that you think should be possible in SIP.
This is of course the most important one to consider.

I'm not claiming solving these requirements satisfy any of the above use
cases - particularly not the last one :-) IMHO the part of the point of
posting this draft was to ask "Do you think a extension to the SIP protocol
that satisfied this set of requirements would be worth doing in the not too
distant future? If not how do these requirements need to change to be useful
for you to build SIP applications that you do believe are useful?"

I realize this is quite fluffy and not very satisfying to be sure we define
a solution to the requirements that picks the optimal solution to any
specific application. It will be interesting to see how the requirements
process evolves in sipping.

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Monday, February 25, 2002 12:31 PM
> To: Mark Watson; [email-masked]; [email-masked]
> Subject: RE: [Sipping] I-D
> ACTION:draft-watson-sipping-req-history-00.txt
>
>
>
>
> From:  Tom Gray@MITEL on 02/25/2002 03:31 PM
>
> It is my understanding that this document is about providing a traditional
> telephony call redirection service within SIP. If that is so, I
> would just like
> a requirements document for this to say that.  If not, it would
> be nice to know
> what is the purpose of the capabilities described.
>
> The capabilites are describing a proposed solution to an unnamed
> problem Calling
> them requirements does not make them so.  Given a derscription of
> the problem
> that is being addressed,  there could be a determination then of
> the information
> that would be need to be carried by SIP for this service and
> whether or not this
> was a problem of broad enough significance that it would be
> addressed in the
> general protocol.
>
>
>
>
> "Mary Barnes" <[email-masked]> on 02/25/2002 03:06:16 PM
>
> To:   Tom Gray/Kan/Mitel@Mitel, "Mark Watson" <[email-masked]>
> cc:   [email-masked]
>
> Subject:  RE: [Sipping] I-D ACTION:draft-watson-sipping-req-history-00.txt
>
>
>
> Tom,
>
> As Mark states, this document wasn't intended to prescribe the
> requirements
> of a solution to solve specific problems or scenarios, but was intended to
> focus on the requirements of the capabilities required in SIP
> (protocol) to
> be able to use SIP as a solution for specific scenarios.
>
> As you say, we've been quite sketchy in describing the scenarios as we had
> assumed the ones that we did use were fairly well known scenarios to the
> audience.  In a sense this document is a guinea pig for the new SIPPING WG
> process and will need refinement.  We can certainly back up yet
> another step
> and add all the details for these scenarios and highlight how these
> scenarios would use the capabilities that have been specified.
> But, I would
> think that would be a rather lengthy document at a fairly high level of
> abstraction as to not be particularly useful either towards the end goal;
> with the end goal of this draft being an acknowledgement that
> there is not a
> "Request History" capability in SIP and that this is necessary in order to
> be able to use SIP for certain services.  We do recognize that
> the level of
> abstraction of the current document is fairly high and we see value in
> taking it to the next step of evaluating different solution proposals
> applied against the required capabilities including specific scenarios to
> demonstrate the proposed solutions. Certainly, this step would be open to
> all "intervenors".
>
> I think the basic question being asked here is whether we want to add more
> to the requirements process by requiring a detailed description and
> agreement of a problem domain prior to proposing requirements for the
> capabilities required in the SIP protocol to solve a given problem? Do we
> have any other opinions, particularly from the WG chairs?
>
> Regards,
> Mary H. Barnes
> [email-masked]
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, February 25, 2002 1:10 PM
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Sipping] I-D
> ACTION:draft-watson-sipping-req-history-00.txt
>
>
>
>
> From:  Tom Gray@MITEL on 02/25/2002 02:10 PM
>
> Reading this document, I do not see how anyone could assess its
> worth. What
> are
> the capabilities identified in this document supposed to accomplish? This
> understanding is what requirements documents are supposed to provide. I
> would
> recommend that the requirements be specific  enough in their problem
> statement
> so that:
>
> a) it could be determined whether or not there is a problem that
> is of high
> enough priority that it needs to be solved. The outcome would naturally be
> an
> agreed upon problem statement. Intervenors could be invited to submit
> proposed
> solutions.
>
> b) the worth of proposed solutions could be assessed by comparing their
> ability
> to solve the agreed upon problems
>
> I see a very general description of a problem area in the
> document. However
> in
> my opinion this could  be greatly improved by providing scenarios which
> illustrate specific deficiencies that are not currently solvable with the
> standard SIP protocol. Without this, I do not see how anyone can
> discuss the
> document. What basis would anyone have for accepting or rejecting it?
>
>
>
>
>
>
> "Mark Watson" <[email-masked]> on 02/25/2002 12:54:33 PM
>
> To:   Tom Gray/Kan/Mitel@Mitel, [email-masked]
> cc:
>
> Subject:  RE: [Sipping] I-D ACTION:draft-watson-sipping-req-history-00.txt
>
>
>
> Tony,
>
> I think it depends what stage in the process you think we are at, and what
> you mean by requirements. 'Requirements' can be written at many
> levels, but
> I thought the stage we got to at the last IETF was a need to identify
> exactly a 'set of capabilities' that we wished to be able to provide with
> SIP.
>
> In terms of the overall problems that these capabilities solve:
> they enable
> certain services, some of which are discussed in the draft and
> some of which
> have been the motivation for the more specific mechanisms previously
> proposed and listed in the references. We don't in IETF define a set of
> services, and then design protocol to implement these, but rather identify
> generic capabilities which might be useful to service designers.
>
> This is where we were after IETF-52, with support for definition of a
> generic capability for request history. Once we have agreement on the
> details of what this capability does, *then* we can proceed to the next
> stage of identifying what technical problems need to be solved from a
> protocol perspective in order to provide achieve this.
>
> We thought this was the required process under sipchange - define the
> capability first in SIPPING and work on the solution later in SIP.
>
> Are you questioning the rationalle for the whole capability, or do you
> expect the requirements to go into more detail as to the effect on the
> protocol ?
>
> Regards,
>
> Mark
>
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: 25 February 2002 15:45
> > To: [email-masked]; [email-masked]
> > Subject: Re: [Sipping] I-D
> > ACTION:draft-watson-sipping-req-history-00.txt
> >
> >
> >
> >
> > From:  Tom Gray@MITEL on 02/25/2002 10:44 AM
> >
> >
> > Looking at this document does not reveal a list of
> > requirements but just a list
> > of proposed capabilities that may or may not require
> > additions to the SIP
> > protocol. For this to be a useful requirement document, this list of
> > capabilities must be linked to a set of problems that need to
> > be solved. Indeed
> > the list of problems would be the nub of the document. For
> > example what problem
> > is the 'capability-req' capability intended to solve. Just
> > what is 'Issuer-req'?
> > The description in the draft doesn't specify this beyond not
> > identifying he
> > reason fro its proposal. What trade-offs if any will  be
> > required for the
> > solution to these problems?
> >
> >
> >
> >
> >
> >
> > [email-masked] on 02/25/2002 06:22:20 AM
> >
> > Please respond to [email-masked]
> >
> > To:   ietf.org
> > cc:   [email-masked] (bcc: Tom Gray/Kan/Mitel)
> >
> > Subject:  [Sipping] I-D ACTION:draft-watson-sipping-req-history-00.txt
> >
> >
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> >
> >
> >      Title          : Generic Request History Capability -
> > Requirements
> >      Author(s) : M. Watson et al.
> >      Filename  : draft-watson-sipping-req-history-00.txt
> >      Pages          : 7
> >      Date      : 22-Feb-02
> >
> > Many services that SIP is anticipated to support require the
> > ability to determine why and how the call arrived at a specific
> > application.  Examples of such services include (but are not limited
> > to) sessions initiated to call centers via 'click to talk' SIP URLs
> > on a web page, 'call history/logging' style services within
> > intelligent 'call management' software for SIP UAs and calls to
> > voicemail servers and call centers.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-watson-sipping-req-h
> istory-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of
> the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with
> the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>      "get draft-watson-sipping-req-history-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>      [email-masked].
> In the body type:
>      "FILE /internet-drafts/draft-watson-sipping-req-history-00.txt".
>
> NOTE:     The mail server at ietf.org can return the document in
>      MIME-encoded form by using the "mpack" utility.  To use this
>      feature, insert the command "ENCODING mime" before the "FILE"
>      command.  To decode the response(s), you will need "munpack" or
>      a MIME-compliant mail reader.  Different MIME-compliant mail readers
>      exhibit different behavior, especially when dealing with
>      "multipart" MIME messages (i.e. documents which have been split
>      up into multiple messages), so check your local documentation on
>      how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> mailto:[email-masked]
> ftp://ftp.ietf.org/internet-drafts/draft-watson-sipping-req-history-00.txt
>
>
>
>
>
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>
>
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Fri, 1 Mar 2002 08:43:40 -0500

From:  Tom Gray@MITEL on 03/01/2002 08:43 AM

These are good examples which should be palced in the requirements draft. They
can be used to assess the worth of any proposed solution.  Some of the scenarios
(especially the looping forwards) given below would seem to be better handled by
other means and some are not really compelling, at least in my opinion. Given
these cases at least a discussion could be held in which various opinions could
be considered. The current version of the draft does not provide any basis for
discussion at all.

"Cullen Jennings" <[email-masked]> on 03/01/2002 01:45:25 AM

To:   Tom Gray/Kan/Mitel@Mitel, "Mark Watson" <[email-masked]>,
      [email-masked]
cc:

Cullen