[Sipconnectit] [SIPForum-techwg] First Pass at a Charter for SIPconnect Interoperability Certification [SC-IT] Task Group

Hutton, Andrew andrew.hutton at siemens-enterprise.com
Wed Mar 21 10:34:53 EDT 2012

Hi All,

I totally agree that the charter should be limited to interoperability testing and certification and any updates to SIP Connect are a separate issue. I don't think the charter should include the statement regarding paying close attention to NENA i3.

During the workshop I did take an action to have a closer look at NENAi3 with regard to any possible incompatibility with the SIPConnect due to the use of REFER.  I will create a separate thread to discuss this issue.


From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of David Hancock
Sent: 21 March 2012 04:02
To: Hadriel Kaplan; Bernard Aboba
Cc: <techwg at sipforum.org>
Subject: Re: [SIPForum-techwg] First Pass at a Charter for SIPconnect Interoperability Certification [SC-IT] Task Group


I agree with your general point here, that both the testing of features/functions not addresses by SC1.1, and the development of updates to SC1.1 are outside the scope of the new SC1.1-Interop working group. My understanding from our discussion at the March 6/7 workshop was -- this new WG would focus on interop testing the capabilities and functions that are in-scope for SC1.1. This includes the features and capabilities that are explicitly identified in SC1.1 (e.g., GIN registration, DID/DOD calls, hold/xfer, call fwding, etc), and also features that aren't explicitly addressed but one would reasonably expect to work (e.g., even though SC1.1 doesn't explicitly mention hunt groups, a SC1.1 DID call to a PBX hunt group pilot number would be expected to work).

SC1.1 Interop testing will surely uncover interworking issues that could be resolved by updates to SC1.1 (updates to clarify ambiguities or correct errors). My memory of the discussion at the workshop was that the SC1.1-Interop W-G would implement an issue tracking process to communicate these issues to a another (technical) W-G for possible resolution in a subsequent point release of the SIPconnect Recommendation.


From: techwg-bounces at sipforum.org<mailto:techwg-bounces at sipforum.org> [techwg-bounces at sipforum.org] On Behalf Of Hadriel Kaplan [HKaplan at acmepacket.com]
Sent: Tuesday, March 20, 2012 5:56 PM
To: Bernard Aboba
Cc: <techwg at sipforum.org<mailto:techwg at sipforum.org>>
Subject: Re: [SIPForum-techwg] First Pass at a Charter for SIPconnect Interoperability Certification [SC-IT] Task Group

OK, I think I grok that. (and you know I've been arguing that the emergency service folks stop inventing new things that only apply to them, for exactly the reasons you cite, so we're in agreement on that :)

So anyway... I don't mean to be an A-hole about this topic, but my concern is this charter makes it sound like the new Task Group is not just about creating a SIPConnect v1.1 test plan, but potentially creating a test-plan for something other than SIPConnect v1.1, or potentially changing SIPConnect v1.1 itself.  For my company, and probably many others, that would involve a different set of people/participants.  We don't let the people who write requirements documents do the testing of the implementation, since they would only be testing what they meant the doc to say, rather than what it actually does say.

Right now all SIP Forum has defined is v1.1, and vendors presumably implemented to that, did their testing for it, and now expect to be certified against it.

If we need to go change SIPConnect v1.1 for NENA, and create a SIPConnect v1.1b, then that's what we need to do, let all the members know about it, and deprecate v1.1.  We might even be able to do it quickly, if it's an emergency. (pun intended :)


On Mar 20, 2012, at 6:47 PM, Bernard Aboba wrote:

I'm NOT defending NENA i3, because I believe SIPconnect 1.1 had sound reasons for its choices -- and it bothers me that all the hard work (and sound reasoning) was ignored in such an important document, particularly given the consequences of interop issues in a SIP trunk used for emergencies.  Personally, I don't believe that a SIP trunk profile used to route emergency calls should handle call transfer differently than for non-emergency calls.   Emergency services need to use mainstream technology as much as possible, because if they don't, then there will be interop issues and bugs that will only pertain to emergency calls, and that is both dangerous and wasteful.  For similar reasons, I don't believe that we need a SIP trunking certification program that pertains solely to SIP trunks used for emergencies.

The above reasoning doesn't imply any technical work for the new Task Group, but it does perhaps point to some marketing/evangelism work that could be done.  For example, there are portions of NENA i3 that refer to simplified calls flows (where typically an SBC is present).  If I had my way, the revision to NENA i3 would be clear about what is mandatory for both the caller and PSAP to support, and those requirements would be harmonized with SIPconnect 1.1.  Since NENA i3 supports a feature set that is larger than SIPconnect 1.1. (e.g. support for text and video communications as well as voice), it's possible that some issues would have to be left for future versions of SIPconnect (e.g. for the Tech WG).  But if we can harmonize the voice call flows soon that would be desirable.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/sipconnectit/attachments/20120321/08def2ad/attachment.html 

More information about the SIPconnectIT mailing list