[SIPForum-discussion] [SIPForum-techwg] Request for Comments -Preliminary Feature Set Document

[Krishnan]

Larry/all,

Agree with Peter and Dan generally. Assuming interoperability starts at
the input interface, the following is for consideration.(I have severe
rib pain due to a major collision on the soccer field; won't able to
talk, will just join in to listen}
   
Since, we are invoking the RFC's,  we have to go back at each instance
to make sure what is minimally required is addressed without being
burdensome. 

#1.	Using a specific example of the input interface using the keypad
the following two paragraphs are extracted from RFC 3966.

	Should there be a sentence along the lines of   " While unsupported in
the URI format, the use of the notation,  is not prohibited."



Request for Comments: 3966  


5.1.2.  Alphabetic Characters Corresponding to Digits

   In some countries, it is common to write phone numbers with
   alphabetic characters corresponding to certain numbers on the
   telephone keypad.  The URI format does not support this notation, as
   the mapping from alphabetic characters to digits is not completely
   uniform internationally, although there are standards
[E.161][T1.703]
   addressing this issue. 

5.1.3.  Alphabetic, *, and # Characters as Identifiers

   As called and calling terminal numbers (TNs) are encoded in BCD in
   ISUP, six additional values per digit can be encoded, sometimes
   represented as the hexadecimal characters A through F.  Similarly,
   DTMF allows for the encoding of the symbols *, #, and A through D.
   However, in accordance with E.164, these may not be included in
   global numbers.  Their meaning in local numbers is not defined here,
   but they are not prohibited.

___________________________________________________________________________________________

#2	In the context of Presence and IM , again from an interactive input
interface standpoint to ensure interoperability,  should the minimal
feature set (standard 104 PC QWERTY keyboard be mandated, recommended
as desirable(additional hot keys hard or soft ) or left unaddressed ? 

RFC 3667 (A Session Initiation Protocol (SIP) Event Package for  Key
PressStimulus (KPML)) 

	doesn't appear to address it. Perhaps it is done elsewhere and some
one could point me in that direction. 

Ravi
(301)404-7319(Mobile)
__________________________________________________________________________



On Tue, 15 May 2007 17:48:11 +0300
 "Romascanu, Dan \(Dan\)" <dromasca at avaya.com> wrote:
> Hi,
>  
> I agree with Peter's points related to the granularity of the
> features
> list - RFC level is certainly too course. 
>  
> Wrt. other supporting features we probably want to discuss - there is
> useful stuff here, but not all necessarily falls under 'SIP Phones
> Interoperability' which is the focus of the document. 
>  
> Missing also are any manageability and reporting capabilities. We may
> want to discuss if they fall within the scope. 
>  
> Dan
>  
>  
>  
>  
> 
> 
>   _____  
> 
> 	From: discussion-bounces at sipforum.org
> [mailto:discussion-bounces at sipforum.org] On Behalf Of
> peter_blatherwick at mitel.com
> 	Sent: Tuesday, May 15, 2007 4:51 PM
> 	To: larry schessel
> 	Cc: Dutkiewicz, Marek; techwg at sipforum.org;
> discussion at sipforum.org; techwg-bounces at sipforum.org
> 	Subject: Re: [SIPForum-discussion] [SIPForum-techwg] Request for
> Comments -Preliminary Feature Set Document
> 	
> 	
> 
> 	Hi all, 
> 	
> 	Sorry for the delay.  I do have some basic comments, for
> discussion on the call today.   
> 	
> 	The general categorization looks basically fine overall, though
> I'm sure we could (and will) dicker over details.   
> 	
> 	My main comment is the content is (so far) basically just a list
> of RFCs, with no support for why that particular list needs to be
> supported.  The sections are called "features" (in Markus' listing),
> but
> do not really list what the features are, just the RFCs.  For
> example,
> if REFER is required, why, what user operations does it support?  I
> think, for each section, we need to outline specifically what
> features
> are expected to be supported, may even need to roughly define the
> features (*gasp*).   Then, what RFCs (perhaps even specific sections)
> are needed to do so.  If there are multiple ways pointed by the RFCs,
> then pick *one*. as the recommended.   
> 	
> 	Another concern is there are other supporting pieces needed to
> provide a quality product.  For example: 
> 	- basic IP networking (eg. Diffserv, including recommended
> DSCPs) 
> 	- IEEE stuff, eg 802.1D/p, 802.1Q, LLDP/LLDP-MED ... 
> 	- Acoustic performance, loss plans and such (can point to TIA
> specs for these) 
> 	I Can gather some refs for these bits if we agree it is needed.
> 
> 	
> 	A small organization thing:  I suggest "Core" be subdivided,
> roughly as follows: 
> 	   6.1 Core functions (basis for all other feature sets 
> 	      6.1.1 Core SIP (current sec 6.1) 
> 	      6.1.2 Core Networking (some of the stuff listed above) 
> 	      6.1.3 Core security (current sec 6.2) 
> 	      6.1.4 Core NAT traversal current sec 6.12 ... assuming we
> would want to say all MUST do NATs) 
> 	
> 	We will also need a section on emergency services support. 
> 	
> 	Hope this helps, and talk to y'all in a few... 
> 	
> 	Peter Blatherwick 
> 	
> 	 
>