Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Tue, 24 Jun 2003 12:17:05 -0700

Hi:

We are very interested in making this a SIPPING WG action item as well.

DND in the true sense rejects any incoming call from being offerred on to
the end device. It is a terminal state like you have indicated in this
email. A presence based implementation that allows calls selectively like
you have indicated could be thought of as a call screening type of
application rather than DND? 

Venkatesh

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, June 24, 2003 6:01 AM
To: [email-masked]
Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt

While there is a lot to like about this draft, I think I could spend
a couple hours poking holes in it.  Let me give you a "for instance":
   DS-6: All SIP business phones MUST support DND. The DND feature, 
   when activated, MUST reject any incoming call meant for the phone 
   with a 486 Busy response code or MAY redirect the call to voice 
   mail.

A presence based implementation of DND might selectively reject calls
based on who is calling.  My wife and possibly my boss might be
able to ring through, most other callers could not.  If I implemented
a phone this way, it would not be compliant with DS-6.

Forwarding for DND might best be done at the proxy server, since you
want it to work if the phone is "down".  

I also object to the language "meant for the phone".  A call to our
phones is "meant for the user", since we require a login.  We have
VERY little phones state, basically just IP addressing things.
Everything else is user based, not phone based.  I wouldn't want to
make it a requirement that DND was phone state.  I would want it
to be possible to have a phone that two users were logged into 
simultaneously, one of which was DND.

I'll do the review work, but first I want to ask if this draft is going
to be the basis of work in the sipping group.  I note that there
are other efforts along similar lines, although this draft is
specific to a "business" phone, if that actually matters.
So, I guess I'm asking two questions:
	Is sipping going to undertake what I would suggest is best
		cast as a BCP on business telephones?
	Is this draft the basis for that work?

I personally think that starting from the work Henry et. al. did is
a better path.  Adding "business" profiles to that would be
one way.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 24, 2003 6:57 AM
> To: @IETF-Announce.{MARCONI}
> Cc: [email-masked]
> Subject: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: SIP-B: SIP for Business Phones 
> Requirements for 
>                           Implementing Business Telephony 
> Features on SIP 
>                           Endpoints
> 	Author(s)	: V. Venkataramanan, S. Rajasekar
> 	Filename	: draft-sharath-sipb-requirements-00.txt
> 	Pages		: 16
> 	Date		: 2003-6-23
> 	
> This informational internet draft describes the requirements for a 
> standard business telephone based on the Session Initiation Protocol 
> (SIP). The objective of this document is to provide a minimum set of 
> requirements for implementing business features on SIP endpoints.  
> This draft is intended to serve as a requirements document for 
> vendors    implementing    business    features    on    SIP    based 
> devices/entities. Details of how each capability or feature is best 
> implemented in SIP, is beyond the scope of this document and may be 
> tracked through the working group draft submissions.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-sharath-sipb-require
ments-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-sharath-sipb-requirements-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-sharath-sipb-requirements-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.

_______________________________________________
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: Henry Sinnreich <[email-masked]>
Date: Wed, 25 Jun 2003 20:09:22 -0500

Venkatesh,

I tend to agree with Brian. It is not quite clear to me what a "business
phone" is today, given that different business users have very different
requirements:

-person in the mail room: the lowest cost phone, no display,

-person in the storage area: cordless 802.11x SIP phone,

-executive desk: high quality speakerphone with rollodex and color
display,

-secretary, receptionist, agent: agent workstation = PC

-cubicle dweller with headset: PC

-travelling employee: laptop or PDA

-nurse in hospital: tablet PC with softclient, etc., etc.

Under these circumstances, what matters is how/what SIP telephony
devices speak  across the wire, auto-configuration process and data
format examples, so that users should not worry how to install and
configure them. The acoustic properties and codecs can be mentioned in
references to TIA and other documents that deal with desktop phones, but
for the reasons shown, I doubt we want to block innovation. Any device
can behave like a phone, even my copy machine/fax - this is not a cute
joke...

In conclusion, I believe "business" phones MUST not be standardized, but
only how they communicate and how they are configured automatically.

If there are missing aspects in the I-D on SIP telephony devices, the
authors will be happy to include your contributions, if they fall into
the scope mentioned: "Just buy and plug it in". Please send any
contributions to the authors and I believe they should also be copied to
the list, so we can discuss.

We respectfully reserve however the right to stick to what we believe is
required to meet the objectives specified in our I-D, since they
represent deployment eperience of large numbers of SIP phones in a large
number of networks.

Henry

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Venkatesh Venkataramanan
> Sent: Tuesday, June 24, 2003 2:17 PM
> To: 'Rosen, Brian'; [email-masked]
> Cc: Sharath Rajasekar
> Subject: RE: [Sipping] I-D 
> ACTION:draft-sharath-sipb-requirements-00.txt
> 
> 
> Hi:
> 
> DND in the true sense rejects any incoming call from being 
> offerred on to the end device. It is a terminal state like 
> you have indicated in this email. A presence based 
> implementation that allows calls selectively like you have 
> indicated could be thought of as a call screening type of 
> Subject: RE: [Sipping] I-D 
> ACTION:draft-sharath-sipb-requirements-00.txt
> 
> 
> While there is a lot to like about this draft, I think I 
> could spend a couple hours poking holes in it.  Let me give 
> you a "for instance":
> A presence based implementation of DND might selectively 
> reject calls based on who is calling.  My wife and possibly 
> my boss might be able to ring through, most other callers 
> could not.  If I implemented a phone this way, it would not 
> be compliant with DS-6.
> 
> Forwarding for DND might best be done at the proxy server, 
> since you want it to work if the phone is "down".  
> 
> I also object to the language "meant for the phone".  A call 
> to our phones is "meant for the user", since we require a 
> login.  We have VERY little phones state, basically just IP 
> addressing things. Everything else is user based, not phone 
> based.  I wouldn't want to make it a requirement that DND was 
> phone state.  I would want it to be possible to have a phone 
> that two users were logged into 
> I'll do the review work, but first I want to ask if this 
> draft is going to be the basis of work in the sipping group.  
> I note that there are other efforts along similar lines, 
> although this draft is specific to a "business" phone, if 
> that actually matters. So, I guess I'm asking two questions:
> I personally think that starting from the work Henry et. al. 
> did is a better path.  Adding "business" profiles to that 
> would be one way.
> 
> Brian
> 
> 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
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>