[Sipconnectit] [Sipnoc-attendees] SIPconnect1.1 test plan feedback

Tue Mar 20 16:26:06 EDT 2012

Howdy,

[speaking as an individual SIP Forum member, nothing else…]

Instead of going point-by-point, I'd just like to comment on #1.  Note I am taking this in the context of a SIPConnect 1.1 compliance and certification program, and the new task group being formed to define the test-plans for such - I am not taking it in the context of SIPit or multi-vendor bake-offs which are different beasts.

During the creation of SIPConnect 1.1 we debated how to account for SBCs/middleboxes on either the Enterprise side or Service-Provider side or both.  The decision was made that SIPConnect 1.1 defines an interface profile between the Enterprise domain and the Service Provider domain, treating each of those domains as a black box.  If there are one or a hundred SBCs, or App Servers, or CSCFs, or whatevers it doesn't matter - the spec defines the Enterprise as a black box, and the Service Provider as another black box.

For example, we didn't want to have to define how an IP-PBX interacts with an E-SBC, vs. how the E-SBC interacts with the SP-SBC, or how the SP-SBC interacts with whatever systems are in the service provider.  The SIPConnect spec's scope, and thus compliance to it, is only between the edges; so if there's an E-SBC at the edge of the Enterprise, the SIPConnect profile applies to what it does between itself and the Service Provider - not what the IP-PBX or UAs behind it inside the Enterprise might or might not do.

We attempted to make that clear in sections 3 (Reference Architecture) and 4 (Definitions) of the profile document, but in hindsight we probably should not have used the term "SIP-PBX" at all in the document since it is confusing and implies something we did not really intend. (or at least, I don't believe it was the intention)

Regardless, since that is the scope of the SIPConnect profile: I  don't believe it's the role of new task group to define tests for something beyond the profile, and thus tests do not need to be defined, nor executed/performed, to verify all possible SIP-PBX/UC-servers can function through all possible E-SBCs to all possible SP-SBCs.  If you make an E-SBC, it's your job to test your product(s) with whatever SIP-PBX/UC-server vendor solutions apply to your market; and likewise if you make an SP-SBC, it's your job to test with whatever Service-Provider equipment applies to your market.  For SIPConnect, the test plans would apply to just the logical interface of the E-SBC to the service provider and vice-versa.

I know that's not perfect, and that in practice it will make a difference which particular IP-PBX/UC-server is behind the E-SBC, and of which version, in what configuration, etc.  But I believe we (a) can't reasonably cover all such possible scenarios, and (b) never defined how those functioned in SIPConnect 1.1, and (c) the SIP-Forum isn't in the business of providing out-sourced integration testing for vendor solutions.

My 2 cents anyway.

-hadriel
p.s. I am not sure why this thread was cc'ed to sipnoc-attendees at sipforum.org<mailto:sipnoc-attendees at sipforum.org>, since that's for discussion about SIPNOC for attendees, not for SIPForum-member feedback on SIPconnect- test plans.  I don't think you meant to do this - it was in John Berg's original email cc list for some reason - just noting I removed it.  Also I removed fullmembers at sipforum, and added sipconnnectit at sipforum.org<mailto:sipconnnectit at sipforum.org> and techwg at sipforum.org<mailto:techwg at sipforum.org> since those are the relevant lists, I think?

On Feb 28, 2012, at 11:45 AM, Karl Stahl wrote:

Here is some promised feedback from Ingate and Intertex (E-SBC vendors with real-life interop SIP Trunking experience toward some 50 ITSPs and 30 IP-PBXs) on the SIPconnect 1.1 test plans.
The test plans are for testing equipment, and then the SIPconnect defined SIP-PBX and SP-SSE are more than the real-life PBX and softswitch, which are assumed to sit on routable IP-addresses without any firewall in between.

1. First let’s introduce the “middle-box” which in our cases are the E-SBCs (Intertex for ITSP’s volume deployments up to 50 simultaneous calls, and the Ingate line for a diversity of installations up to many thousands of calls) and on the ITSP side there are often bigger middle-box SBCs.
The middle-box is required at least for NAT/firewall traversal of SIP into a private IP domain (typically a LAN, or an SP’s “core network” shielded off by a firewall). (If someone mentions MPLS or some other “VPN-pipe” as “a solution”, that is just extending the private domain until a “middle-box” located more centrally makes the NAT traversal into another domain.) The middle-box is most often also used to fix up SIP things in the PBX or a softswitch, or worse, may also introduce its own peculiarities.
The idea of SIPconnect and standards in general is of course that they are followed at all points, to ease interoperability.
It should be understood that “middle-boxes” can be transparent SIPconnect compliant (must act like a SIP proxy then), or be compliant towards the ITSP while fixing up the PBX, or be compliant towards the PBX and fix up the ITSP. (Yes, our products do all of that.)
Having said that, the SIPconnect test plan should also consider “middle-boxes”. Even if a softswitch/SBC or PSTN gateway combination is considered as an SP-SSE and a PBX/E-SBC combination is considered as an SIP-PBX, the goal must be that the individual components also are compliant.
1.1 So, having PBXs tested as the defined SIP-PBX and a softswitch, a gateway or a SIP registrar-proxy tested as a SP-SSE, there is also a need to test middle-boxes.
1.2 If, ideally, both the PBX and the softswitch/gateway/registrar-proxy are SIPConnect compliant, then the middle-box could and should behave like a SIP proxy, being transparent to SIPconnect, which must be tested.
It must be tested that the middle-box “in SIP proxy mode” handles all SIP compliant and especially the RFC 6140 Gin registration, both in registration and static mode. (Registration mode requires some special handling.). (An SBC typically forwards incoming SIP calls by having a copy of a previous registration in its own “shadow registrar” or by some configuration that could be seen as a static registration). Other things to check are that Call IDs and sequence numbers are being maintained and that via headers are added, route header functions, all the TLS stuff and more.
1.3 However, middle-boxes, may also act as B2BUAs (Our E-SBCs can do both proxy and B2BUA modes, on a per call basis, even though there is a large difference.). B2BUA mode is typically required in combination with non compliant PBXs or softswitches to do more “SIP normalization” than a proxy can do.
In these cases, the test approach must be test a combination of softswitch or PSTN gateway/SBC as an SP-SSE and a combination of a PBX/E-SBC as a SIP-PBX. That can of course not be as general as the testing in SIP proxy mode can be. However the capabilities of being a Gin registrar or a Gin registrant could of course be tested against existing test plans.
It must be noted, that ITSPs deploying SIP trunking, often do not want to trust the customer/PBX with the digest password to their service, but instead provision the password to the E-SBC that hides it and does the authentication instead of the actual PBX. This forces that E-SBC to be a B2BUA. (A better approach would be to use mutual TLS, where the SP can trust the E-SBC through its certificate, and then with less risk let the PBX have the digest password. See further the mutual TLS discussion under 3 below.)

2. ITSP’s show a great variation in the interface to their SIP trunk services - much more than the PBX side. Even if many of the ITSPs use the same softswitch and SBC, their interfaces are most often different. There seems to be many configuration opportunities in a softswitch and then there are even more settings and “SIP header manipulation” in the SBCs (What an ugly thing – Yes, our products have it also, but rather to “un-manipulate”, in case functional remedies are not enough.) The same applies even if the ITSP call its service IMS-based.
So, to get things standardized, it is not enough that vendors participate in SIPconnectit. It is  most important that the ITSP’s participate! Will they? Will there be SIPconnect certifications for ITSPs?

3. TLS and mutual TLS (i.e. the PBX side also having a certificate that is being checked by the SP side)
Both the CableLabs and the UNH-IOL test plans include mutual TLS tests. However, SIPconnect 1.1 only prescribes TLS. The SIPconnect spec therefore also mandates “The SIP-PBX MUST initiate the establishment of the TLS session.” and “The SIP-PBX and the SP-SSE MUST avoid closing down the TLS connection”, that could be released if mutual TLS was used.
Mutual TLS also is also good for an SP to be in control of a middle-box via its certificate (as discussed above).
So, should the test plans be seen as a recommended addition to SIPconnect, or a pre 1.2 requirement or what?
You may also want look at http://internetplus.ingate.com for the benefit of a middle-box certificate. In that model, the TOQrouter could be the registrar with Gin capabilities for PBX registration and would otherwise also accept SIPconnect 1.1 as a subset. (The TOQrouter routes PSTN calls to the SP’s PSTN gateway or SBC/softswitch combination.)

4.  How complete are the test plans? As mentioned above, the ITSP side has most variations from standard SIP and thus SIPconnect 1.1. Below I therefore list some of the issues we have had to compensate for in real life SIP trunking. Here the test plans may not yet consider some of these things. A comparison between the CableLabs and the UNH-IOL test plans will of course be beneficial for completeness.
4.1 ITSP side examples of SIP deviations – Test that these fixes are not needed! :)
The picture is from the Web GUI in our E-SBCs (here the small Intertex IX78, but it is essentially the same in the Ingate line of larger E-SBCs). These setting represent real-life requirements that have occurred over many years. (There are more settings, but this is what we found had to be applied per ITSP’s SIP Trunk – we can have up to 9 such individual trunks groups. In addition, in some cases we have had to also apply “header manipulation”).
<image001.png>
4.1.1 Used when the SIP Trunk is provided on other pipe than the Internet, where the customer also uses SIP (and data) via the same E-SBC. (Not within the test scope I guess.)
4.1.2 There are various ideas of what has to be in the From header domain of outgoing calls. I think the test plans straighten that up already.
4.1.3 For incoming calls, a few ITSPs actually put very strange things in the host part of the request URI (calling it Trunk ID), making a proper SIP implementation wanting to look that up in DNS and route… Forbid!
4.1.4 RFC 4904 (Trunk group parameters) is not allowed with SIPconnect.
4.1.5 Some ITSPs have too low (e.g. 5 instead of recommended 75!) max forwards causing routing problems.
4.1.6 Often media is only accepted from the signaling IP address, or may cause hang up problems forwarded calls.
4.1.7 IMS systems have been found to refuse calls respondiong “Not exactly one via header”!? Forbid!
4.1.8 Gin registration I guess you like to see that as the default :) , but not used yet…
4.1.9 Same as 4.1.7, but here for Record-Route. (Since these headers have a meaning – one cannot just “manipulate them away”. A middle-box then has to store previous and then reinsert on the way back – Puh…)
4.1.10 IMS systems also seem to object to the forking of their calls by hanging up (I guess they think they own the specific receiving terminal by some magic…). So here we filter to only show one To-tag in the ring backs. Check that ringback from several clients are allowed!
4.1.11 Sometimes we have to modify the domain in the Contact header of 3xx responses.
4.1.12 Incoming calls should only be routed based on Request URI (not on To header or P-Called-Party-ID found in IMS).
4.1.13 The use of P-Asserted-Identity and P-Preferred-Identity varies wildly. I think that is in the test plans already.
4.1.14 There are other settings for number mapping, registration and authentication variations and what should be in the P-Asserted fields. Those looks tested in the plans.
4.1.15 The use of Refer is often a problem. At least the Cable Labs test plan seems to forbid it (prescribes 3GPP style – using reinvite instead), but is it not open in SIPconnect? (In B2BUA mode we middle-box translate Refer to reinvite, but that cannot be done in proxy mode where Refers are passed on.)

4.2 PBX side
The SIP trunking interfaces of PBXs are generally quite basic and have not “invented so many special things”, so I believe the test plans are quite complete there.

5) Beyond POTS replication
SIP Connect 1.1 is mainly an interface for the POTS service (E.164 numbers and audio only), but it really does not have to be. Just minor additions are required to allow all kinds of SIP services. Having a 1.2 version would encourage PBX vendors to put PBXs UC capabilities on their SIP Trunking interface also. PBX vendors don’t even call their machines PBXs anymore, and there is no reason why their “UC machines” with video, IM and Presence just are local or only federate via complex proprietary IP-plumbing.
Since SIPconnect 1.1 emphasizes that the INVITE can contain multiple media descriptions - at least that should be tested for proper behavior for future compatibility. I could not find that in the test plan (only CableLabs’ browsed).

6) Future
Going beyond the POTS service (we cannot stay there another 100 years, having all that bandwidth and capacity in PCs terminals and smartphones), we cannot push all SIP into the POTS replicating peering between carriers, but have to go IP all the way over a common IP-network and really deliver SIP (Not POTS limited SIP!) all the way between users and SIP servers. (Would we have had the Web if HTTP only could be used for videotext when handed over between different ISPs?)
Have a look at http://internetplus.ingate.com or http://internetplus.intertex.com to see how that can be realized and also give Telcos new revenue, when delivering more capacity and quality bandwidth!
Internet+ will of course be compliant with SIPconnect 1.1 for PBX POTS services and with a slightly extended SIPconnect 1.2 for full UC services.

/Karl
Ingate & Intertex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/sipconnectit/attachments/20120320/a65b40c4/attachment-0001.html 