[SIPForum-techwg] (Interop) SHOULD in RFCs...

[Chandra]

Hi friends,

 

I agree with Peter and Syed.

 

SIP should (not "may":-)) be compatible and suffice to specific usages. Be
it a mobile or an embedded or a simple UA or it could be a soft phone in a
enterprise or a contact center. Considering the enormity of IMS - IVVR and
SIP's integration with parlay API to provide application integration.. All
these have different requirements and need specific approaches.

 

In the recent Voicecon 2007 Art Ross has presented some (I too contributed
my 2 cents!!!) questions to a panel of Nokia and Cisco on the unified view..
Some of them are related to SIP, specific to SIP based call controls - Third
party call controls...

 

Any thought process..?

 

Re

Chandra Pillai

 

  _____  

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
Behalf Of Ahmad, Syed
Sent: Monday, April 23, 2007 7:09 PM
To: Peter Musgrave; techwg at sipforum.org
Subject: Re: [SIPForum-techwg] (Interop) SHOULD in RFCs...

 

Peter,

 

Excellent point.

 

May be:

Learn from how Bluetooth is handled with various Spec profile support
(http://www.bluetooth.com/Bluetooth/Learn/Works/Profiles_Overview.htm)

Problem: Too many profiles (although some profiles are part of a group of
profiles - so may be not so bad after all).

 

Learn from how Java is handled with editions:

Java 2 Micro Ed, Standard Ed, Enterprise Ed so imagine (SIP Micro Ed for may
be just basic residential telephony ? etc )

 

We need to also remember that SIP is inherently not for just "Telephony" -
although that is where the most push is.

So may be another idea would be to divide SIP spec into sections that handle
various commuication mediums, or various device types

SIP for Telephony, SIP for Video, SIP for Broadcast, SIP for ...

 

Just adding my 2 cents.

 

Syed Ahmad 
========================
Senior Engineer, Sales & Marketing Department 
Panasonic Communications Co (UK) Ltd 
Pencarn Way, Duffryn, Newport, South Wales, NP10 8YE,UK
Email:syed.ahmad AT eu.panasonic.com (replace AT with @)
Web:  <http://pccuk.panasonic.co.uk/> http://pccuk.panasonic.co.uk/
Tel: +44 (0) 1633 653600 (Ext. 131) 
Fax: +44 (0) 1633 810041 
=========================== 

 

 

  _____  

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
Behalf Of Peter Musgrave
Sent: 23 April 2007 13:48
To: techwg at sipforum.org
Subject: [SIPForum-techwg] (Interop) SHOULD in RFCs...

Hi, 

 

As part of trying to define specific interop requirements for use-case I
decided to start with looking at the SHOULD clauses in the RFCs from Section
(6). Past experience at SIPITs suggest to me that these clauses cause a
number of interop issues, in part because a number of parties interpret a
SHOULD as MAY..

 

To remind myself SHOULD means.

   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

 

So how many SHOULDs are there?

RFC2246 - 0

RFC2283 - 6

RFC2782 - 8

RFC3261 - 276

RFC3262 - 9

RFC3263 - 16

RFC3264 - 27

RFC3311 - 8

RFC3323 - 23

RFC3324 - 0

RFC3325 - 2

RFC3489 - 26

RFC3581 - 5

RFC3725 - 19

RFC4028 - 18

 

So the winner by far is RFC3261 (which is also the longest spec). 

 

This represents a fairly large degree of freedom in establishing interop. 

 

Should we be more specific in listing the requirements for interop? If we
*really* want guaranteed interop then every SHOULD which will impact interop
will need to be resolved. 

 

Do we have the collective appetite for this?

 

Peter

 

 

 



Note:
Email domain @kmeuk.co.uk will change to @eu.panasonic.com.
ie: john.brown at kmeuk.co.uk changes to john.brown at eu.panasonic.com. Please
update your contact details now.


............................................................................
..
Confidentiality Notice
The information contained in this Email, and any attachments, is intended
for the named recipients only. It may contain confidential and/or legally
privileged information. If you are not the intended recipient, you must not
copy, store, distribute or take any action in reliance on it. Any views
expressed do not necessarily reflect the views of the company.

If you receive this Email by mistake, please advise the sender by using the
reply facility in your Email software and then delete it.
............................................................................
.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20070424/48e3ffa3/attachment.html