[Sipconnectit] SIPconnect1.1 test plan feedback

[Karl Stahl]

Hi there,

 

Regarding:

> how to account for SBCs/middleboxes on either the Enterprise side or
Service-Provider side or both. . - the spec defines the Enterprise as a
black box, and the Service Provider as another black box.  

 

A clear definition of the spec (here SIP Connect 1.1) and an interface
surface, do not mean that we can ignore having every step in the chain
follow the standards.

 

If you run real-time protocols (here SIP) into private domains (non IP
routable networks, usually separated by a firewall), middle boxes are
introduced (Today's firewalls, do unfortunately not have functional SIP ALGs
- they would then be Firewalls with a built in SBC as the terminology has
evolved.).

 

IP-PBXs usually reside on LANs (the most typical private domain), and a
middle-box must therefore be SIP Connect compliant to make that
specification meaningful. A service provider running SIP in a private domain
(at least for any better thought than just gatewaying all SIP into the PSTN)
must also be able to assure that SIP Connect 1.1 passes and gets in and out
of their private domains, and allow SIP communication.

 

Thus, it is highly important that SIP and SIP Connect 1.1 compliance of
middle boxes can be checked via the test plan discussed. 

 

Also, consider that Service Providers (e.g. represented by CableLabs, highly
engaged in the test plan as well as making the ESG specification of an E-SBC
type of middlebox) should be able to require "SIP Connect 1.1 compliance" in
their RFIs/RFPs for middle boxes. Another example is Deutsche Telecom, with
plans of moving over to their "All-IP" network. Only in the SMB segment,
they need a million middle-boxes and have expressed their wish to only
bother with connecting SIP Connect compliant PBXs.

 

 

Going back to the test cases:

 

In last email (below) I forgot to mention another issue seen in at least one
IMS system, making it useless for the UDP SIP Trunking it was configured for
- something that the test plan otherwise include.

 

It was the use of the IMS header P-Associated-URI, where that IMS system in
a single UDP register response listed all 500 numbers of the SIP trunk in
such headers, generating a 10kB or so fragmented UDP-packet (and there may
be more numbers in a trunk). Such long UPD packets are not even handled by
the operating systems typically used in PBXs, so the test plan should watch
the maximum UDP length used. Let's say it should be less than 3kB. This
would not be a problem using TCP, but SIP's recommended going over from UDP
to TCP does not apply to responses and is generally poorly implemented
anyway (another thing to test). (We have found more SIP implementations
getting confused by moving over from UDP to TCP for long SIP requests, than
having problems with fragmented UDP.)

 

/Karl

Ingate & Intertex

 

 

From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com] 
Sent: den 20 mars 2012 21:26
To: Karl Stahl
Cc: David Hancock; John Berg; Daryl Malas; <sipconnectit at sipforum.org>;
techwg at sipforum.org
Subject: Re: [Sipnoc-attendees] SIPconnect1.1 test plan feedback

 

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, 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 and
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>
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>
http://internetplus.ingate.com or  <http://internetplus.intertex.com>
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/20120423/6dd2fd07/attachment-0001.html