Background

The Polycom SoundPoint IP SIP Phones and Adtran IADs are used for Hosted IP PBX Access Devices, managed by the BroadWorks platform. In a non-geographically-redundancy network, the devices use SIP to register to a single SIP SBC IP address.

To support geographic redundancy of SBCs, the devices must support registration to multiple IP addresses. It must select the proper IP address in each case to maintain its service and operation on the platform.

polycom_adtran_sbc_georedundancy_1In a conventional non-redundant design, each SIP Access device registers with only a single SBC. In a geo-redundant environment the SIP Access Device has to decide properly when and if to use each of the two sites.

The behavior of a SIP Access Device controls the effectiveness of geo-redundant failover. There are no hard and fast standards on the proper behavior. For example:

  • How does the access device determine that the primary site is unavailable?
  • After determining the primary site is unavailable, what should happen to calls that had already been started through that site?
  • How long should the access device wait before attempting to register with the secondary site?
  • After successfully registering with the secondary site, when should the access device check the status of the primary site?
  • Should the access device check the status of the primary site with a SIP registration, or some other SIP method?
  • What happens to SIP subscriptions setup on the access device during a failover to a secondary site?

This TR documents the best results determined for supporting this service on the Polycom SIP phones and geo-redundant SBCs, supported by BroadWorks.

Failover Retransmission Timing

Polycom –

Failover is based on a lack of response for both Polycom 3.x and 4.x software. It uses a 2-exponential backoff starting at 500 ms with a maximum delay of 2000 ms.

Assuming a SIP REGISTER 200 OK Contact expires=30 value causing the phone to re-register every 30 seconds, the worst-case timeline for failover is as follows, for both Adtran TA900 and Polycom phones.

  • Time <0: Device Under Test (DUT )receives 200 OK for SIP REGISTER
  • Time 0: DUT is successfully registered.
  • Time 15: DUT transmits REGISTER to lab-sd1
  • Time 15.5: DUT retransmits REGISTER to lab-sd1
  • Time 16.5: DUT retransmits REGISTER to lab-sd1
  • Time 18.5: DUT transmits REGISTER to lab-sd2
  • Time >18.5: DUT successfully registers via lab-sd2

Times are given in seconds.

Adtran –

The IAD uses a 2-exponential backoff starting at 500 ms with a default maximum delay of 2000 ms.

Assuming default settings, the worst-case timeline for failover is as follows.

  • Time <0: Device Under Test (DUT )receives 200 OK for SIP REGISTER
  • Time 0: DUT is successfully registered.
  • Time 15: DUT transmits REGISTER to lab-sd1
  • Time 15.5: DUT retransmits REGISTER to lab-sd1
  • Time 16.5: DUT retransmits REGISTER to lab-sd1
  • Time 18.5: DUT transmits REGISTER to lab-sd2
  • Time >18.5: DUT successfully registers via lab-sd2

Times are given in seconds.

Subscriptions

Polycom –

SIP Subscriptions are lost when the DUT re-registers with the secondary SBC. They are re-established after an hour. DUT does not re-SUBSCRIBE when it switches to a new SBC. BroadWorks does not keep the subscriptions coupled to the registration Contact which would route through the user’s current SBC.

Because subscriptions are not maintained between SBCs, features such as these will not be fully functional during the hours:

  • Busy Lamp Field
  • Shared Call Appearance
  • Message Waiting Indicator

Adtran –

SIP Subscriptions are not applicable when dealing with Adtran IADs.

Testing
Polycom SIP Version 3

The Polycom 3.x software is the newest software available for many popular phones, including the SoundPoint IP 330 and 500. Therefore, for networks that include these and related generations of phones, the geo-redundancy behavior of these devices affects the core network operation significantly.

In the tests below, the DUT is a Polycom SoundPoint IP 330 running 3.1.2c software.

Configuration and DNS Lookups

The DUT was configured to perform DNS lookups for “lab2.e-c-group.com”, and configured for transport=”DNSnaptr”.

@ORIGIN lab2.e-c-group.com.
_sip._udp 600        IN        SRV 20 10 5060 lab-sd2
_sip._udp 600        IN        SRV 10 10 5060 lab-sd1
lab-sd1   600        IN        A              216.128.128.11
lab-sd2   600        IN        A              216.128.128.40

Fault Detection

DUT detects the fault only when it fails to receive a reply to a SIP REGISTER.

If the SBC returns a SIP 400 or SIP 503 response to DUT, DUT does not attempt lab-sd2.

Affinity for Active SBC

Every new registration request restarts on the primary SBC.

And, even after registered on the secondary SBC, lab-sd2, every new INVITE is attempted on the primary SBC.

Revert

Because every new request is attempted in the primary SBC, each new REGISTER or INVITE will cause an attempt to revert to the primary SBC.

Key Findings

Geographic Failover Should Work

The Polycom 3.x software should provide a functional failover option.

Overload-After-Recovery Risk

Polycoms running 3.x will attempt to register with a recovered SBC during the registration expiration interval. For example, if all devices are configured to re-register every 30 seconds, and the Polycoms re-attempt registration at half of the registration expiration time, then every Polycom 3.x device will attempt to register with the primary SBC, after its recovery, in the space of 15 seconds. This is likely to cause an overload on the newly-recovered SBC.

Polycom SIP Version 4

The Polycom 4.x software is available for many of Polycom’s newer SoundPoint IP Phones, such as the 550 and 670. This software provides several additional configuration options for proper support of failover.

Parameter Explanation Default Recom-
mendation
authOptimizedInFailover If set to 1, when failover occurs, the first new SIP request is sent to the server that sent the proxy authentication request.

If set to 0, when failover occurs, the first new SIP request is sent to the server with the highest priority in the server list.

0 1
onlySignalWithRegistered If 1, the phone determines if the user is registered (voIpProt.SIP.outboundProxy.failOver.RegisterOn must be enabled). 1 1
failRegistrationOn If 1, the phone will silently invalidate an existing registration at the point of failing over. 1 1
failOver.failBack.mode The mode for failover failback.

 

newRequests – all new requests are forwarded first to the primary server regardless of the last used server.

DNSTTL – the phone tries the primary server again after a timeout equal to the DNS TTL configured for the server that the phone is registered to.

registration – the phone tries the primary server again when the registration renewal signaling begins.

 

duration – the phone tries the primary server again after the time specified by …failOver.failBack.timeout expires.

newRequests DNSTTL
reRegisterOn If 1, the phone will first attempt to register with (or via) the server to which the signaling is to be diverted, and only if the registration succeeds (200 OK with valid expires) will the signaling diversion proceed with that server. 0 1

Configuration and DNS Lookups

The DUT was configured to perform DNS lookups for “lab2.e-c-group.com”, and configured for transport=”DNSnaptr”.

We tested with both TCP and UDP on the Polycom 4.x software.

TCP Configured

@ORIGIN lab2.e-c-group.com.
@         600        IN        NAPTR 50 10 "S" "SIP+D2T" "" _sip._tcp
_sip._udp 600        IN        SRV   20 10 5060             lab-sd2
_sip._udp 600        IN        SRV   10 10 5060             lab-sd1
lab-sd1   600        IN        A                            216.128.128.11
lab-sd2   600        IN        A                            216.128.128.40

UDP Configured

@ORIGIN lab2.e-c-group.com.
_sip._udp 600        IN        SRV 20 10 5060 lab-sd2
_sip._udp 600        IN        SRV 10 10 5060 lab-sd1
lab-sd1   600        IN        A              216.128.128.11
lab-sd2   600        IN        A              216.128.128.40

Fault Detection

DUT detects the fault only when it fails to receive a reply to a SIP REGISTER.

If the SBC returns a SIP 400 response to DUT, DUT does not attempt lab-sd2.

If the SBC returns a SIP 503 response, the DUT attempts to re-register with lab-sd2. But it does not stay registered properly with lab-sd2; it allows the registration to expire. In effect, when the primary SBC returns a SIP 503, the DUT stays registered only part of the time.

Affinity for Active SBC

Using the settings that we recommend in this document, DUT continues to consistently use a specific SBC until it fails, or the DNS TTL timer expires.

Revert

Using the recommendations of this document, DUT will continue to use the secondary SBC for the duration specified by DNS TTL value. After this expires, DUT will re-attempt the primary SBC.

Key Findings

Geographic Failover Should Work

The Polycom 4.x software should provide a functional failover option. Because the affinity/revert function is less aggressive than the 3.x software, the 4.x software should provide better functionality for a geographically-redundant system.

Adtran TA900E IAD

Testing began with firmware version A4.07.00E. However, due to an issue with this version of the firmware the failover SIP register command is malformed. Thus, a firmware upgrade is required to allow the Adtran DUT to support failover. The firmware was upgraded to the most recent version of R10.5.0E.

Configuration and DNS Lookups

The DUT was configured to perform DNS lookups for “lab2.e-c-group.com”. However, the Adtran IADs only support “SRV” lookup and have no support for “DNSnaptr”. The DUT does correctly prioritize the SBCs based on the DNS lookup.

Fault Detection

DUT detects the fault primarily when it fails to receive a reply to a SIP REGISTER. If the SIP Trunk setting “sip-server rollover service-unavailable-or-timeout” is set then failover on a SIP 503 response can occur for requests other than SIP REGISTER.

If the SBC returns a SIP 400 response to DUT, DUT does not attempt lab-sd2.

Affinity for Active SBC

Every new registration request restarts on the primary SBC.

And, even after registered on the secondary SBC, lab-sd2, every new INVITE is attempted on the primary SBC.

Revert

Because every new request is attempted in the primary SBC, each new REGISTER or INVITE will cause an attempt to revert to the primary SBC.

Key Findings

Geographic Failover Should Work with updated firmware

The A4.07.00E software sends malformed the failover SIP messages. However, the R10.5.0EE firmware for the Adtran IAD will provide a functional failover option.

Overload-After-Recovery Risk

Default Adtran IAD configurations will attempt to register with a recovered SBC during the registration expiration interval. For example, if all devices are configured to re-register every 30 seconds, and the IAD re-attempts registration at half of the registration expiration time, then every IAD will attempt to register with the primary SBC, after its recovery, in the space of 15 seconds. This is likely to cause an overload on the newly-recovered SBC.

Lab Testing

Test-By-Test Lab Testing records are available here. In these tests, we used the following equipment:

  • Polycom SoundPoint IP 330 0a1e
  • Polycom SoundPoint IP 601 35b2
  • Polycom SoundPoint IP 550 28ec8e
  • Adtran TA 908e
  • Acme Packet NN4250, 6.2 software, lab-sd1
  • Acme Packet NN4250, 6.2 software, lab-sd2
  • BroadWorks R18 Lab, lab2.e-c-group.com
  • Cisco Small Business SG300-10P PoE Ethernet Switch

 

This article based on ECG Tech Report TR-ECG15273.
Lab Testing: Matt Keathley

 

Question:

How do you make a display filter that filters out most RTP frames, but leaves a representative sample? Sometimes it’s convenient to see a sampling of RTP frames in Wireshark, without having to see 50 per second.

Answer:

Rather then see 50 frames per second for every RTP flow, how about one frame every 5 seconds?

Wireshark display filter:

rtp[3:1]==0 or rtp.marker==1

Shows an RTP packet for each RTP stream
— about every 5 seconds
— or when the stream starts afresh

How does it work?

  • The 3rd and 4th bytes of the RTP frame are sequence number
  • The sequence number increases monotonically (40704, 40705, 40706, etc.)
  • rtp[x:y] gives the Y-number of bytes that appear at X-offset in the RTP frame, where the first byte in the packet is at 0 offset
  • rtp[3:1] gives the 1 byte that appears in the 4th byte of the frame (see the “00” in attached screenshot). This is the least-significant byte of the number.
  • Normal VoIP RTP sends 1 frame every 20 millseconds
  • Since the RTP frame is a 2-byte value, then 1 out of every 256 frames will have a least-significant-byte value of 0
  • 256 [sequence numbers] * 20 ms = 5.12 seconds
  • I’m glossing over some details in the previous two points
  • Each time a new RTP flow starts, the sender should send an RTP frame with rtp.marker==1

When you’re connecting to the rest of the world to make and receive phone calls, you have several design options available. Or, more precisely, your Voice Service Providers have many options available.

VoIP via Layer-3 VPN

In this case, a Layer-3 VPN, such as MPLS over the Voice Provider’s own equipment, is used to connect a Voice customer to the Voice service provider. Shared infrastructure is used, but the traffic from the Internet cannot route to the Voice equipment. The same physical links might carry Internet traffic as well, as shown on black hairline from the Internet Service Providers to the Customer Data Network.
In this case, a Layer-3 VPN, such as MPLS over the Voice Provider’s own equipment, is used to connect a Voice customer to the Voice service provider. Shared infrastructure is used, but the traffic from the Internet cannot route to the Voice equipment. The same physical links might carry Internet traffic as well, as shown on black hairline from the Internet Service Providers to the Customer Data Network.

MPLS is the way we see this implemented most commonly. In this case, the customer has a location and an MPLS or Ethernet VPN path back to the Voice Service Provider.

Pros

+ Protection against bad days on the Internet. E.g., if global BGP is working poorly. Or if “Cyber Warriors” in a despotic regime decide to launch a Denial of Service (DoS) attack against voice networks.

+ Usually it’s easier to prioritize traffic in a VPN.

+ The Voice Service Provider can ensure end-to-end quality of service if they want to because they own or manage all the queues (i.e., routers and switches) along the path from their equipment to the enterprise.

Cons

– You have to depend on the reliability of the MPLS path; it’s usually harder to have redundant links to the Voice service provider.

VoIP via Internet Infrastructure

The Voice Service Provider and the Customer both connect to the Internet and  exchange the IP addresses of their equipment. SIP and RTP are unencrypted. Devices accept or reject SIP calls based on the incoming IP address.
The Voice Service Provider and the Customer both connect to the Internet and exchange the IP addresses of their equipment. SIP and RTP are unencrypted. Devices accept or reject SIP calls based on the incoming IP address.

No special MPLS is used here, but we depend on the same shared routers.

Pros

+ The Voice Service Provider is also an ISP, and they manage all of the queues. So if they want to, they can provide high Quality of Service.

+ Usually there is no congestion inside Service provider networks. They can upgrade their links easily an inexpensively to get adequate capacity.

+ Potential for backup options via the public Internet.

Cons

– Bad things on the Internet might affect this; e.g., DoS attacks, or BGP malfunctions. However, within a service provider’s own network, the effects can often be mitigate.

– Sometimes harder to do QoS; not for technical reasons, but because ISPs are sometimes no good at prioritizing packets or guaranteeing bandwidth.

VoIP via VPN Over the Internet

In this model, the Voice Service Provider and the customer both connect to the Internet. A VPN, such as IPSEC VPN or permanent TLS connection, is setup across the Internet between the two parties. At least the SIP Signaling traverses the VPN.
In this model, the Voice Service Provider and the customer both connect to the Internet. A VPN, such as IPSEC VPN or permanent TLS connection, is setup across the Internet between the two parties. At least the SIP Signaling traverses the VPN.

Pros

+ Get to choose from among any ISP

+ Assuming the Customer has Internet access, there’s no construction time required to setup

+ Protection against IP address spoofing in either direction; so if you receive a SIP packet you can trust it was genuinely sent from the service provider

Cons

– No protection against unreliability on the Internet

– No quality of service can be guaranteed

– The links between the Voice service provider and the ISP may be questionable. For example, if a streaming video service, like Netflix, goes into business, certain Internet links that worked in the past may become saturated.

– IPSEC tunnels add extra complexity to the system.

VoIP via Internet

The Voice Service Provider and the Customer both connect to the Internet and  exchange the IP addresses of their equipment. SIP and RTP are unencrypted. Devices accept or reject SIP calls based on the incoming IP address. The Voice Service Provider may not have a ”Provider-Edge” router at all.
The Voice Service Provider and the Customer both connect to the Internet and exchange the IP addresses of their equipment. SIP and RTP are unencrypted. Devices accept or reject SIP calls based on the incoming IP address.
The Voice Service Provider may not have a ”Provider-Edge” router at all.

Pros

+ Get to choose from among any ISP

+ Assuming the Customer has Internet access, there’s no construction time required to setup

Cons

– No protection against unreliability on the Internet

– No quality of service can be guaranteed

– Risks of poor quality due to congestion on the Internet.

The BroadSoft BroadWorks DBS is a different animal than other BroadWorks servers, and it requires a special set of commands to keep it alive and well. The level of care and feeding required for the database reminds of BroadWorks App Server release R12 and R13; those were not happy days.

Check status of the FRA Disk Group

  • dbsctl diskinfo
  • /etc/init.d/oracleasm listdisks
    • On a healthy, normal system, this should list two entries: DATA and FRA
  • bwBackup.pl
  • srvctl status diskgroup -g FRA
  • As root: /sbin/blkid | grep asm

Installation Logs

These show a lot of what happen when installing the Oracle parts of the DBS:

  • /var/broadworks/logs/installation/oracle*
  • /u01/app/oraInventory/logs/installActions* show

Convert a standalone DBS to be a secondary DBS

  1. Clear ASM DATA and FRA disk groups
  2. Install DBS on DBS2 as a standalone primary
  3. On the primary/active DBS: use config-ssh to mesh both bwadmin and oracle accounts
  4. On the other DBS which will become the standby: sitectl convert bwCentralizedDbX
  5. On the primary/active DBS: peerctl add dbs2

Fix the kernel 2.6.18-400.1.1.el5 name mismatch for OracleASM

Upgrading to the BroadWorks DBS R20sp1 requires a kernel update. As of 2014 December 19, updating the RHEL 5 kernel installs version 2.6.18-400.1.1.el5.

However, only oracleasm-2.6.18-400.el5-2.0.5-1.el5 is available from Oracle.

However, the kernel module appears to be cross-compatible. Here’s how I moved it:

mkdir -p /lib/modules/2.6.18-400.1.1.el5/kernel/drivers/addon/oracleasm
cp /lib/modules/2.6.18-400.el5/kernel/drivers/addon/oracleasm/oracleasm.ko /lib/modules/2.6.18-400.1.1.el5/kernel/drivers/addon/oracleasm
cat /lib/modules/2.6.18-400.el5/modules.dep >> /lib/modules/2.6.18-400.1.1.el5/modules.dep

Submit your favorite tidbits in comments!

“Network Neutrality” advocates teach us that banning certain Active Queue Management (AQM) algorithms will result in greater freedom on the Internet. For example: Barack Obama wants to ban “Paid Prioritization,” which Cisco calls “Low Latency Queueing”.

Even folks interested in computers, but who don’t build or run networks, seem to have some downright strange opinions. For example, when Netflix became a customer of Comcast, Ben Gilbert at Engadget claimed Netflix was “paying off” Comcast”. When I buy a 50 Mbps link from Time Warner, instead of a 5 Mbps link, is the extra $30/month “paying them off”?

Net Neutrality and Freedom of the Press

American Journalist A.J. Liebliing famously wrote, “Freedom of the press is guaranteed only to those who own one.” The folks who run routers and network links are something like the owners of printing presses. If our government restrict the rights of someone who owns a computing device which copies and transmits information, isn’t that a violation of a basic right of humankind?

It’s Distributed Computing, Not Common Carriage

Somehow, ISPs have been confused with Fedex. While a common carrier delivers an entire package or a working application, ISPs carry only packets. British Consultant and Scientist, Martin Geddes, argues strongly that the Internet is not “common carriage” like the postal service, but truly a distributed computing platform. It doesn’t make sense to treat an ISP like UPS or the Royal Mail when “packets are merely arbitrary divisions of data flows. Broadband is fundamentally different from other forms of common carriage infrastructure. . . Packets are not people, and you don’t need to be ‘fair’ to them. There is no good karma in being even-handed to fragments of data flows in flight. It is only the fairness to people that we care about, which means only end user outcomes matter.”

Netflix’s Self-Destructive Taste in ISPs

Cogent is among the cheapest and worst of the “tier 1” ISPs. Netflix bought Internet access through Cogent, but unlike other web-hosting companies, Cogent doesn’t expect to pay money to interconnect with other ISPs. Historically, this type of unpaid peering has been agreeable because customers (downloaders) and data sources (servers) were distributed roughly equally across the Internet.

So when Cogent needed bigger links to deliver Netflix data — i.e., they wanted to install additional 10 Gbps Ethernet links to other ISPs — they expected to get them for free and pass the savings on to Netflix. Cogent would pay for their router and their ports, but they expected Level(3), Comcast, and others to provide free access to router ports on their side.

It normally doesn’t work that way. But because Cogent and Netflix had a business model built around the historical unpaid peering, it was very difficult for them to switch.

But why can’t we stop Comcast from Mangling our Data?

But Netflix’s choice of Cogent as an ISP and a naÏve business model — has gotten conflated with Comcast’s 2008 penchant for throttling Internet speeds. The FCC promised to enforce a ban on Internet throttling. “We need to protect consumers’ access, said FCC Chairman Kevin Martin, a Republican. “While Comcast has said it would stop the arbitrary blocking, consumers deserve to know that the commitment is backed up by legal enforcement.” So according to the FCC, “throttling” Internet access is already against the law.

Why is Netflix complaining? Because they don’t want to have to pay much for their Internet links.

But Why do I Have So Few ISP Choices? I hate my ISP!

Many homes and businesses in America have three ways of getting Internet access:

  • THE telephone company’s voice-grade cable.
  • Coax from the cable company.
  • Wireless radio signal.

Telephone Wires, 1933 Edition

The telephone wires were built to support voice and  voice only. But with the advent of “DSL,” the same wires are good enough for a substantial Internet connection. There are more tricks coming to increase spectral efficiency, but for most folks, their Internet speed via DSL is between 3 and 6 Mbps.

Why is their only one telephone company who owns the wire going to your building? In the early 1930s, offering telephone service for all Americans became a national priority. But laying the wires to deliver all this service is quite expensive. Through the early 20th century, a bargain was developed, so that each telephone company:

  • Had to promise to offer service to every address in its territory
  • …And would get a monopoly on some territory of the country
  • And would be guaranteed some minimum profits.

That national priority allowed the monopoly, and that’s why you have only one telephone company in most places.

If you’re guaranteed minimum profits, then if your costs go up 10%, then you can raise your rates at least 10% with the government’s blessing. So even as technology improved, the telephone companies had no incentive to minimize costs. Vendors took note.

Telephone Wires, 1996 Edition

In 1996, the telecom act allowed anybody to become a telephone company in the US. You had a to follow all the same rules, but if you did, you could buy Unbundled Network Elements including access to the copper wires that connected to each home. The logic was something like this: the telephone companies got a fabulous deal and government-sponsored loans for most of the 20th century, and the infrastructure built with that government assistance should be available to other players for more innovation.

Many ISPs and telephone companies have been built on those new rules. And the price of local service and of long distance in the United States has dropped precipitously, along with the stock value of telecom vendors like Nortel that were built on the shoulders of the overpriced telecom rules from the 1930s.

While the FCC made a good start at implementing these rules, they became convinced that they weren’t really necessary. The telephone companies had no incentive to unbundled their network elements, and they found ways to get out of offering new services, like fiber links, to their “competitor” wholesale operators.

Dane Jasper of Sonic.net argues that reinvigoration of the 1996 Telecom Act would do a lot to bring more competition. “I call on the FCC to reconsider the decisions of that past era, and to take steps to reintroduce UNE-L (unbunded network element: loop) requirements, including access to available dark fiber, which is a critical backhaul component for competitive carriers. Copper unbundling is only fully viable when the middle mile fiber isn’t missing from the equation.” Ironically, the laws requiring this are already on the books.

Cable Television Wires

I’m no expert on cable television vendors, but in my experience on a project in South Georgia I learned that the cable companies are granted a local monopoly, a franchise, which allows them to sell services to limited households, and gives them the “pole-attach” rights they need to run their  cables around town.

Entertainment services were not a major priority initially. But because of the vast bandwidth requirements of serial, analog television, the technology used — coax — delivers enormous capacity for Internet access. In the FCC parlance, Cable Internet providers are considered “fiber” because they use fiber optic cables to deliver “Hybrid-Fibert-Coax” Internet to neighborhoods. The total bandwidth available over coax cable is well over 1 Gbps.

So it was local regulation, and the high cost of construction, that means most folks only have one provider for Oprah re-runs and for Coax-based Internet. My understanding is that there are no general rules preventing multiple coax or fiber providers from delivering service. If you can sign a contract with your local town, you can offer high-speed Internet there by building a new HFC network. If you have a small town of 10,000 homes, Cisco expects it to cost around $5.6 million (i.e., $561 per household-passed by the coax).

Wireless Internet

Wireless Internet, including LTE, is available to lots of folks as of my writing. But as of now, it’s also relatively expensive to deliver a megabit over LTE or EV-DO. You can expect this to change and become a viable alternative.

Engadget and others have it wrong.

Engadget’s deceptive depiction of ISPs suggests there’s some beautiful spaghetti cable connecting your ISP to all the web sites. In reality, each party — both each house, and each “website” has to pay the ISP to provide a service to it.

Engadget seems to think that services like Netflix and Amazon are like the water we drink, falling freely from the sky, while ISPs are collecting it and charging you a fee. The model is completely wrong: Netflix and Amazon buy access plug into the ISP’s equipment, just like homes and businesses do.  And if Netflix doesn’t buy enough access, they’ll have slow Internet, just like you do.

Would Net Neutrality Raise Your Internet Bill?

Under modern telecom rules in the US, unlimited long distance talking is essentially free. Under the old rules, AT&T would offer a discount price of only $0.11 per minute — but only during certain days, after certain hours.

We know that telephone service was drastically overpriced prior to the 1996 Telcom Act; we know this because the prices dropped as soon as technology could be developed to exploit the new freedoms under Federal Law.

It seems likely that placing additional restrictions on telephone service would be on-sided, guaranteeing only additional freedoms and guarantees to consumers. It would be a compromise, with ISPs promised guaranteed minimum profitability in exchange for certain difficulties.

And that compromise — in the name of freedom — would be likely to introduce a new era of overpriced telecom.

So, What’s The Solution?

The Cisco Small Business SPA-500 series phones (such as the SPA-502G, SPA-508G) include a Cisco-signed SSL certificate. Until very recently, all of the Cisco SPA-500-series phones shipped were signed by a Sipura certificate. Sipura was the Korean company that was bought by Linksys before Linksys was bought by Cisco.

Sometime after August 2013, Cisco Small Business started shipping phones signed with a different certificate. Cisco Small Business failed to inform the largest telephone company in the world so it could prepare for this change.

Cisco has issued a new certificate that can be used to verify the new client certificates. Dan Lukes used the Cisco discussion forum to helpfully post the new certificates. We’re all glad Cisco hosts the site to enable their customer Dan Lukes to post the information that Cisco should have posted.

Using Apache HTTPD, you can load the text below as a certificate, then setup a directory to require the client certificate:

        SSLCACertificateFile /etc/httpd/conf/ssl.crt/cisco_small_business_cert_20140802.crt
        <Location /spa500>
              SSLRequireSSL
              SSLVerifyClient require
              SSLVerifyDepth 10
        </Location>

In honor of the United States’ Belt-and-Suspenders approach to ebola prevention, 200OK.info is posting the certificate here.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            d0:7d:8c:15:c0:ba:7c:b6:44:69:98:b1:ea:89:87:9f
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=California, L=San Jose, O=Cisco Small Business, OU=Cisco Small Business Certificate Authority, CN=Cisco Small Business Client Root Authority 2/emailAddress=ciscosb-certadmin@cisco.com
        Validity
            Not Before: Aug  2 22:37:43 2013 GMT
            Not After : Jun 28 22:37:43 2035 GMT
        Subject: C=US, ST=California, L=San Jose, O=Cisco Small Business, OU=Cisco Small Business Certificate Authority, CN=Cisco Small Business Client Root Authority 2/emailAddress=ciscosb-certadmin@cisco.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:bf:c2:f8:3a:e6:c6:89:21:8c:82:a0:79:91:73:
                    72:f3:74:d5:a8:4e:a7:3d:7b:02:ab:6b:2c:8d:71:
                    82:02:76:7a:fa:bf:2e:8c:e7:b0:47:15:96:ab:83:
                    8f:48:0d:e7:e7:15:f2:ed:54:2e:cd:7d:e3:36:34:
                    f6:eb:05:a3:d5:39:57:2e:6a:ee:b2:0a:b7:7b:a6:
                    dd:82:e9:6a:94:01:2f:89:1d:52:93:f4:ec:23:08:
                    ae:6f:04:0a:94:5d:92:94:d6:3a:c4:58:69:da:2b:
                    2e:64:cf:77:0e:29:82:c3:be:7d:7a:eb:f8:f4:d1:
                    5c:18:77:85:a4:5e:e8:1e:51:f6:d4:79:f1:e1:c8:
                    44:7c:67:ad:9c:f7:9b:80:74:1f:32:05:79:c3:d5:
                    67:41:df:1c:80:9a:10:57:80:9b:7e:ab:e6:50:24:
                    82:42:06:cf:df:34:7d:0a:e9:70:56:dc:6f:0a:c5:
                    1b:32:7a:f0:e1:73:2e:21:d4:92:7a:d6:53:96:83:
                    b3:8d:82:bc:7f:5e:03:ed:e9:7e:63:39:bb:37:0a:
                    c6:32:c7:fe:db:3f:b0:8a:02:85:83:78:2a:87:32:
                    5a:b1:82:ff:38:df:0d:4b:83:31:8e:af:78:e6:79:
                    46:94:8e:2e:c3:18:34:36:31:90:b6:3a:89:1e:06:
                    1a:67
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                F8:C2:33:67:A9:12:FC:5D:43:23:9E:55:D3:7E:57:40:1A:55:42:10
            X509v3 Authority Key Identifier:
                keyid:F8:C2:33:67:A9:12:FC:5D:43:23:9E:55:D3:7E:57:40:1A:55:42:10
                DirName:/C=US/ST=California/L=San Jose/O=Cisco Small Business/OU=Cisco Small Business Certificate Authority/CN=Cisco Small Business Client Root Authority 2/emailAddress=ciscosb-certadmin@cisco.com
                serial:D0:7D:8C:15:C0:BA:7C:B6:44:69:98:B1:EA:89:87:9F

            X509v3 Basic Constraints:
                CA:TRUE
            Netscape Cert Type:
                SSL CA
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
    Signature Algorithm: sha1WithRSAEncryption
        98:95:36:35:98:51:26:92:66:c6:db:cd:ad:1a:a9:7f:12:2c:
        02:c3:36:28:4f:05:20:f3:85:a2:a1:f7:4d:6c:4b:68:47:0a:
        6f:f9:f3:6e:fa:e7:cf:cc:57:a5:7f:60:d6:d9:ba:7f:f3:81:
        16:e2:d7:c5:83:0c:1a:84:82:24:9a:ab:5f:20:5c:21:26:24:
        b7:6d:03:5f:ad:8e:10:9b:8c:2b:9a:6c:bc:a0:0c:4d:5c:52:
        d7:00:bb:ff:b9:73:aa:17:69:98:ca:a5:4c:79:bc:9e:73:48:
        b1:b5:c1:90:d8:88:89:f4:a2:55:bb:78:6b:e8:91:37:19:3f:
        37:7d:20:c4:ea:c1:f3:17:f1:4f:49:b5:6d:fe:f3:24:3b:f1:
        84:98:d0:0e:f4:24:bd:7e:e7:86:ee:6f:ff:7d:6c:49:fa:75:
        4d:d9:eb:f8:7c:1f:cd:3d:c3:16:33:23:38:8c:96:72:62:50:
        2d:6f:ea:68:0c:a6:ba:bb:0e:08:f5:5d:e9:c0:d2:c9:be:f3:
        ae:73:ae:63:ba:f6:8d:34:e9:60:b1:6e:a2:f8:cb:8b:fd:03:
        2c:c1:91:e0:45:12:e6:26:98:8a:51:16:6f:5c:36:20:6f:fd:
        99:96:3a:7b:8b:b1:56:2c:de:b7:91:ec:36:bc:14:56:c3:df:
        62:fd:d4:36
-----BEGIN CERTIFICATE-----
MIIF7zCCBNegAwIBAgIRANB9jBXAuny2RGmYseqJh58wDQYJKoZIhvcNAQEFBQAw
gewxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMREwDwYDVQQHEwhT
YW4gSm9zZTEdMBsGA1UEChMUQ2lzY28gU21hbGwgQnVzaW5lc3MxMzAxBgNVBAsT
KkNpc2NvIFNtYWxsIEJ1c2luZXNzIENlcnRpZmljYXRlIEF1dGhvcml0eTE1MDMG
A1UEAxMsQ2lzY28gU21hbGwgQnVzaW5lc3MgQ2xpZW50IFJvb3QgQXV0aG9yaXR5
IDIxKjAoBgkqhkiG9w0BCQEWG2Npc2Nvc2ItY2VydGFkbWluQGNpc2NvLmNvbTAe
Fw0xMzA4MDIyMjM3NDNaFw0zNTA2MjgyMjM3NDNaMIHsMQswCQYDVQQGEwJVUzET
MBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxHTAbBgNVBAoT
FENpc2NvIFNtYWxsIEJ1c2luZXNzMTMwMQYDVQQLEypDaXNjbyBTbWFsbCBCdXNp
bmVzcyBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxNTAzBgNVBAMTLENpc2NvIFNtYWxs
IEJ1c2luZXNzIENsaWVudCBSb290IEF1dGhvcml0eSAyMSowKAYJKoZIhvcNAQkB
FhtjaXNjb3NiLWNlcnRhZG1pbkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC/wvg65saJIYyCoHmRc3LzdNWoTqc9ewKrayyNcYICdnr6
vy6M57BHFZarg49IDefnFfLtVC7NfeM2NPbrBaPVOVcuau6yCrd7pt2C6WqUAS+J
HVKT9OwjCK5vBAqUXZKU1jrEWGnaKy5kz3cOKYLDvn166/j00VwYd4WkXugeUfbU
efHhyER8Z62c95uAdB8yBXnD1WdB3xyAmhBXgJt+q+ZQJIJCBs/fNH0K6XBW3G8K
xRsyevDhcy4h1JJ61lOWg7ONgrx/XgPt6X5jObs3CsYyx/7bP7CKAoWDeCqHMlqx
gv843w1LgzGOr3jmeUaUji7DGDQ2MZC2OokeBhpnAgMBAAGjggGIMIIBhDAdBgNV
HQ4EFgQU+MIzZ6kS/F1DI55V035XQBpVQhAwggErBgNVHSMEggEiMIIBHoAU+MIz
Z6kS/F1DI55V035XQBpVQhChgfKkge8wgewxCzAJBgNVBAYTAlVTMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMREwDwYDVQQHEwhTYW4gSm9zZTEdMBsGA1UEChMUQ2lzY28g
U21hbGwgQnVzaW5lc3MxMzAxBgNVBAsTKkNpc2NvIFNtYWxsIEJ1c2luZXNzIENl
cnRpZmljYXRlIEF1dGhvcml0eTE1MDMGA1UEAxMsQ2lzY28gU21hbGwgQnVzaW5l
c3MgQ2xpZW50IFJvb3QgQXV0aG9yaXR5IDIxKjAoBgkqhkiG9w0BCQEWG2Npc2Nv
c2ItY2VydGFkbWluQGNpc2NvLmNvbYIRANB9jBXAuny2RGmYseqJh58wDAYDVR0T
BAUwAwEB/zARBglghkgBhvhCAQEEBAMCAgQwEwYDVR0lBAwwCgYIKwYBBQUHAwIw
DQYJKoZIhvcNAQEFBQADggEBAJiVNjWYUSaSZsbbza0aqX8SLALDNihPBSDzhaKh
901sS2hHCm/5827658/MV6V/YNbZun/zgRbi18WDDBqEgiSaq18gXCEmJLdtA1+t
jhCbjCuabLygDE1cUtcAu/+5c6oXaZjKpUx5vJ5zSLG1wZDYiIn0olW7eGvokTcZ
Pzd9IMTqwfMX8U9JtW3+8yQ78YSY0A70JL1+54bub/99bEn6dU3Z6/h8H809wxYz
IziMlnJiUC1v6mgMprq7Dgj1XenA0sm+865zrmO69o006WCxbqL4y4v9AyzBkeBF
EuYmmIpRFm9cNiBv/ZmWOnuLsVYs3reR7Da8FFbD32L91DY=
-----END CERTIFICATE-----

For completeness, this is the older Certificate:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            45:bf:48:c0:ce:b8:8f:7b:c8:e1:6d:85:62:5a:5b:8f
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=US, ST=California, L=San Jose, O=Sipura Technology, Inc., OU=Sipura Technology Certificate Authority, CN=Sipura Technology Client Root Authority 1/emailAddress=webmaster@sipura.com
        Validity
            Not Before: Feb  7 22:29:57 2004 GMT
            Not After : Jan 30 22:29:57 2034 GMT
        Subject: C=US, ST=California, L=San Jose, O=Sipura Technology, Inc., OU=Sipura Technology Certificate Authority, CN=Sipura Technology Client Root Authority 1/emailAddress=webmaster@sipura.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:e7:21:ce:9b:39:d1:18:1b:d3:c7:50:b5:fc:8c:
                    71:a9:9d:72:5c:1a:64:8c:fc:fd:a6:51:c6:b2:41:
                    ee:2f:c9:ec:13:d3:9b:4c:af:ec:1a:93:43:6b:c4:
                    2e:00:45:29:d2:49:14:db:f9:f1:1b:f0:1f:28:b4:
                    53:c0:63:fc:85:b4:3d:f5:e9:5c:3b:e7:57:bf:b5:
                    e4:19:fc:93:3f:ec:d0:ea:ae:de:aa:42:0a:2d:fa:
                    33:8f:42:bf:69:b9:4f:ce:12:34:52:26:3f:f8:01:
                    d2:56:69:70:9e:01:c5:62:d6:13:94:f2:06:dc:e2:
                    af:3e:ef:2b:2a:c5:55:a5:f5
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                4C:83:38:2B:9D:C6:E3:65:AB:19:51:31:A5:C9:35:9B:51:0A:23:21
            X509v3 Authority Key Identifier:
                keyid:4C:83:38:2B:9D:C6:E3:65:AB:19:51:31:A5:C9:35:9B:51:0A:23:21
                DirName:/C=US/ST=California/L=San Jose/O=Sipura Technology, Inc./OU=Sipura Technology Certificate Authority/CN=Sipura Technology Client Root Authority 1/emailAddress=webmaster@sipura.com
                serial:45:BF:48:C0:CE:B8:8F:7B:C8:E1:6D:85:62:5A:5B:8F

            X509v3 Basic Constraints:
                CA:TRUE
            Netscape Cert Type:
                SSL CA
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
    Signature Algorithm: md5WithRSAEncryption
        8e:ea:90:83:84:b9:9f:d7:8d:77:65:e0:42:cd:d2:71:58:23:
        51:41:5e:52:df:10:55:4e:4f:03:19:41:6e:02:d8:4f:f8:ce:
        4b:7e:6f:2a:95:b2:7d:55:b2:c2:f4:ff:37:03:87:e1:b0:9d:
        c3:b2:64:8a:bb:f3:c2:7e:c2:8f:46:b0:9d:e9:2b:d0:f4:b1:
        81:d4:5a:21:f0:0b:14:d1:09:da:30:a6:6e:63:09:8b:f7:9f:
        b9:81:8f:b5:a9:0c:34:8f:9e:6d:6e:4a:50:92:e3:71:66:86:
        56:ca:e0:f9:3c:39:5f:e3:9c:d2:d6:7b:65:35:22:09:6f:fa:
        a0:e9
-----BEGIN CERTIFICATE-----
MIIEyjCCBDOgAwIBAgIQRb9IwM64j3vI4W2FYlpbjzANBgkqhkiG9w0BAQQFADCB
4jELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNh
biBKb3NlMSAwHgYDVQQKExdTaXB1cmEgVGVjaG5vbG9neSwgSW5jLjEwMC4GA1UE
CxMnU2lwdXJhIFRlY2hub2xvZ3kgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MTIwMAYD
VQQDEylTaXB1cmEgVGVjaG5vbG9neSBDbGllbnQgUm9vdCBBdXRob3JpdHkgMTEj
MCEGCSqGSIb3DQEJARYUd2VibWFzdGVyQHNpcHVyYS5jb20wHhcNMDQwMjA3MjIy
OTU3WhcNMzQwMTMwMjIyOTU3WjCB4jELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
bGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMSAwHgYDVQQKExdTaXB1cmEgVGVj
aG5vbG9neSwgSW5jLjEwMC4GA1UECxMnU2lwdXJhIFRlY2hub2xvZ3kgQ2VydGlm
aWNhdGUgQXV0aG9yaXR5MTIwMAYDVQQDEylTaXB1cmEgVGVjaG5vbG9neSBDbGll
bnQgUm9vdCBBdXRob3JpdHkgMTEjMCEGCSqGSIb3DQEJARYUd2VibWFzdGVyQHNp
cHVyYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOchzps50Rgb08dQ
tfyMcamdclwaZIz8/aZRxrJB7i/J7BPTm0yv7BqTQ2vELgBFKdJJFNv58RvwHyi0
U8Bj/IW0PfXpXDvnV7+15Bn8kz/s0Oqu3qpCCi36M49Cv2m5T84SNFImP/gB0lZp
cJ4BxWLWE5TyBtzirz7vKyrFVaX1AgMBAAGjggF9MIIBeTAdBgNVHQ4EFgQUTIM4
K53G42WrGVExpck1m1EKIyEwggEgBgNVHSMEggEXMIIBE4AUTIM4K53G42WrGVEx
pck1m1EKIyGhgeikgeUwgeIxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9y
bmlhMREwDwYDVQQHEwhTYW4gSm9zZTEgMB4GA1UEChMXU2lwdXJhIFRlY2hub2xv
Z3ksIEluYy4xMDAuBgNVBAsTJ1NpcHVyYSBUZWNobm9sb2d5IENlcnRpZmljYXRl
IEF1dGhvcml0eTEyMDAGA1UEAxMpU2lwdXJhIFRlY2hub2xvZ3kgQ2xpZW50IFJv
b3QgQXV0aG9yaXR5IDExIzAhBgkqhkiG9w0BCQEWFHdlYm1hc3RlckBzaXB1cmEu
Y29tghBFv0jAzriPe8jhbYViWluPMAwGA1UdEwQFMAMBAf8wEQYJYIZIAYb4QgEB
BAQDAgIEMBMGA1UdJQQMMAoGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBAI7q
kIOEuZ/XjXdl4ELN0nFYI1FBXlLfEFVOTwMZQW4C2E/4zkt+byqVsn1VssL0/zcD
h+GwncOyZIq788J+wo9GsJ3pK9D0sYHUWiHwCxTRCdowpm5jCYv3n7mBj7WpDDSP
nm1uSlCS43FmhlbK4Pk8OV/jnNLWe2U1Iglv+qDp
-----END CERTIFICATE-----

Thanks to my colleague Jon Chleboun, as well as Daniel Cruz, and Dan Lukes.

When it comes to telephones, everybody has certain expectations.

Nobody wants a phone that fails occasionally. And most service providers have a model of phone that they trust; nobody wants to try out a new SIP phone and learn that it fails in an obscure, but important feature.

For example: Have you seen the new Yealinks? Or what about the improved Grandstreams?   How do you ensure the phone is going to do everything you need it to do — like those unusual things a receptionist does, that a technician or engineer never does?

Below  you can find a set of 152 Test Criteria (TC’s) I’ve used to test new models of SIP phones. If you develop test procedures to confirm each of these criteria are met, you’ll have a good idea that the SIP phone is going to do all the PBX functions for a SIP phone.

Using these criteria requires you to have a general understanding of Service Provider VoIP. To develop a test procedure to confirm TC1, “Proper Registration via SBC.” The value of this list is to help you remember things you might have forgotten otherwise, and expedite testing procedures.

Mark’s 152 Test Criteria for SIP Phones

TC1 : Proper Registration via SBC

TC2 : Symmetric signaling (SIP to and from the same UDP port) and media (RTP to and from the same port)

TC3 : PSTN to SIP call, calling party disconnects first

TC4 : PSTN to SIP call, called party disconnects first

TC5 : SIP to PSTN call, calling party disconnects first

TC6 : PSTN to SIP call, called party disconnects first

TC7 : SIP to SIP call for each supported model or software version (e.g., Aastra 57i/2.2.0 calling to PolyCom SPIP 601)

TC8 : Calling-Party Name and Number display for “on-net” VoIP-CPE-to-VoIP-CPE calls

TC9 : Calling-Party Name and Number display for calls received from each PSTN carrier

TC96 : Called Party name displays on intra-group calls and calls to group-call-park

TC29 : Auto-answer for click-to-dial calls (i.e., supports SIP INVITE with alert to make calling phone automatically pick up)

TC39 : Calls sent to the DUT but not answered

TC40 : Calls placed by DUT but not answered

TC41 : DUT installed behind firewall with NAT

TC42 : DUT installed behind firewall with no NAT

TC43 : SIP over TCP (for devices that support it)

TC103 : Call Forward Always using key on phone and signaling on phone

TC51 : Call Forward Always using key on phone, synchronized with BroadWorks/Metaswitch/Feature Server settings

TC104 : Do-Not-Disturb using key on phone and signaling on phone

TC52 : Do-Not-Disturb using key on phone, synchronized with BroadWorks/Metaswitch/Feature Server settings

TC53 : DUT can be configured match Service Provider’s standard digit map (aka “dial plan”)

TC106 : DUT can dial calls the same whether the phone is off hook or on hook

TC84 : DUT re-registers a 5-15 seconds before the old registration expires.

TC10 : Call hold and retrieve using hold button or soft key on DUT

TC11 : Remote-party call hold and retrieve (i.e., the remote end of the conversation puts the call on hold, not the DUT)

TC12 : Three-way calling

TC13 : Three-way call disposition when DUT disconnects from call

TC14 : Blind transfer

TC15 : Consultative transfer

TC16 : Shared Call Appearance (SCA)

TC17 : Busy Lamp Field (BLF)

TC18 : Multiple lines configured on one telephone

TC19 : Proper NTP synchronization of clock display

TC20 : Long-call-duration calls

TC21 : Call Forward Always using key on phone

TC22 : Do-Not-Disturb using key on phone

TC23 : Multiple buttons configured for the same line

TC24 : DTMF transfer to Media Server, Conferencing Server, Auto Attendant server, etc.

TC25 : DTMF transfer to PSTN via PSTN gateway(s)

TC57 : PLAR / Automatic Ring-Down: DUT can be configured to automatically dial a number when the handset is lifted

TC67 : DUT should support up to 6 inbound calls stacked up (ringing inbound to phone) and function properly

TC68 : When you have lots of inbound calls stacked up, you can put a call on hold and park the most-recently-active call

TC69 : When call parked by the DUT reverts to the DUT phone, the DUT phone can retrieve the call properly

TC111 : When DUT transfers a call, and the Call Transfer Recall timer reverts the call back to DUT, it can retrieve the call properly

TC70 : DUT can call into a 10-line paging group and automatically announce to those lines

TC71 : DUT can be a member of a 10-line paging group, so that when the group is called it automatically goes on speaker and announces what the caller says

TC72 : (Push-to-Talk) Hoot-and-Holler call outbound: DUT can call to another phone and have it go off hook on speakerphone

TC73 : (Push-to-Talk) Hoot-and-Holler call inbound: DUT can receive an inbound call and have it go off hook on speakerphone

TC110 : Auto-answer “Push-to-talk” calls and sets up two-way conversation

TC85 : DUT supports Broadworks/Metaswitch N-Way conferencing (Low-priority test).

TC86 : DUT can put a call on hold and retrieve it 5 times, and have two-way audio each time the call is un-held.

TC87 : DUT can be on a call where the remote party puts the call on hold and retrieves is 5 times, and have two-way audio each time the call is un-held.

TC112 : DUT works properly with BroadWorks/Metaswitch Group Call Park

TC88 : DUT operates as any party in any call transfer scenario

TC88.1 : Blind transfer, original recipient is facilitator

TC88.1.a : Blind transfer, original recipient is facilitator, DUT is originator

TC88.1.b : Blind transfer, original recipient is facilitator, DUT is original recipient

TC88.1.c : Blind transfer, original recipient is facilitator, DUT is final recipient

TC88.2 : Blind transfer, originator is facilitator

TC88.2.a : Blind transfer, originator is facilitator, DUT is originator

TC88.2.b : Blind transfer, originator is facilitator, DUT is original recipient

TC88.2.c : Blind transfer, originator is facilitator, DUT is final recipient

TC88.3 : Blind transfer before call answer, original recipient is facilitator

TC88.3.a : Blind transfer before call answer, original recipient is facilitator, DUT is originator

TC88.3.b : Blind transfer before call answer, original recipient is facilitator, DUT is original recipient

TC88.3.c : Blind transfer before call answer, original recipient is facilitator, DUT is final recipient

TC88.4 : Blind transfer before call answer, originator is facilitator

TC88.4.a : Blind transfer before call answer, originator is facilitator, DUT is originator

TC88.4.b : Blind transfer before call answer, originator is facilitator, DUT is original recipient

TC88.4.c : Blind transfer before call answer, originator is facilitator, DUT is final recipient

TC88.5 : Attended transfer, original recipient is facilitator

TC88.5.a : Attended transfer, original recipient is facilitator, DUT is originator

TC88.5.b : Attended transfer, original recipient is facilitator, DUT is original recipient

TC88.5.c : Attended transfer, original recipient is facilitator, DUT is final recipient

TC88.6 : Attended transfer, originator is facilitator

TC88.6.a : Attended transfer, originator is facilitator, DUT is originator

TC88.6.b : Attended transfer, originator is facilitator, DUT is original recipient

TC88.6.c : Attended transfer, originator is facilitator, DUT is final recipient

TC88.7 : Busy-Failed Blind transfer, original recipient is facilitator

TC88.7.a : Busy-Failed Blind transfer, original recipient is facilitator, DUT is originator

TC88.7.b : Busy-Failed Blind transfer, original recipient is facilitator, DUT is original recipient

TC88.7.c : Busy-Failed Blind transfer, original recipient is facilitator, DUT is final recipient

TC88.8 : Busy-Failed Blind transfer, originator is facilitator

TC88.8.a : Busy-Failed Blind transfer, originator is facilitator, DUT is originator

TC88.8.b : Busy-Failed Blind transfer, originator is facilitator, DUT is original recipient

TC88.8.c : Busy-Failed Blind transfer, originator is facilitator, DUT is final recipient

TC88.9 : No-Answer-Failed Blind transfer, original recipient is facilitator

TC88.9.a : No-Answer-Failed Blind transfer, original recipient is facilitator, DUT is originator

TC88.9.b : No-Answer-Failed Blind transfer, original recipient is facilitator, DUT is original recipient

TC88.9.c : No-Answer-Failed Blind transfer, original recipient is facilitator, DUT is final recipient

TC88.10 : No-Answer-Failed Blind transfer, originator is facilitator, DUT is originator

TC88.10.a : No-Answer-Failed Blind transfer, originator is facilitator, DUT is originator

TC88.10.b : No-Answer-Failed Blind transfer, originator is facilitator, DUT is original recipient

TC88.10.c : No-Answer-Failed Blind transfer, originator is facilitator, DUT is final recipient

TC44 : DUT downloads via FTP/TFTP/HTTP/HTTPS and ability to detect and download new configurations

TC49 : Request IP address via DHCP upon phone startup

TC50 : Request IP address after lease expiration or after loss of Ethernet connectivity without power-cycling phone

TC46 : Detect voice and VLAN tags automatically (e.g., using CDP or 802.1AB/LLDP)

TC47 : 802.1q VLAN tagging on “LAN” port

TC48 : Function as Ethernet switch or hub for PC port. The DUT should switch data-VLAN traffic to the PC port, removing the VLAN tag. It should also switch frames received on the PC port to the LAN port, adding the appropriate VLAN tag.

TC54 : When using PoE, DUT should request a reasonable amount of power

TC56 : The switch in the phone should pass through untagged frame (i.e., any frame with no 802.1q vlan tag) from between the PC port and the LAN port to support the PC/access VLAN being untagged while the voice VLAN is tagged.

TC59 : DUT can locate the SIP server using SRV records.

TC60 : Locate the SIP server using A-record lookups for an outbound proxy.

TC64 : When using a wireless handset, it should work in the presence of moderate or heavy 802.11 traffic

TC74 : DUT can be rebooted remotely from the Reset function in BroadWorks/Metaswitch

TC75 : DUT creates logs of call activities and events

TC76 : DUT logs call statistics (packet loss, jitter, codec, etc.)

TC77 : DUT can upload its log to a server using FTP

TC78 : DUT with built-in switch can support wire-rate 100 Mbps for a PC plugged in behind the phone

TC79 : DUT with built-in switch works OK if device behind PC sends wake-on-LAN packets when it goes to sleep or wakes from sleep

TC80 : DUT works when connected to a network with 10% broadcast or multicast traffic loads

TC81 : DUT does not have a significantly-increased CPU load level in presence of 10% broadcast or multicast traffic loads (low-priority test: do this last)

TC82 : DUT works when connected to a standard customer-premise network switch configuration

TC89 : DUT can automatically detect when new firmware is available (by polling the server to check for new software), then selectively download and upgrade itself only when new software is available.

TC90 : DUT downloads new firmware using authenticated FTP.

TC93 : DUT can download new configurations and configurations via FTP using the username and password specified with DHCP response Option 66

TC94 : DUT can download new configurations via HTTPS using the username and password specified with DHCP response Option 66

TC105 : A brand-new-out-of-the-box DUT can be upgraded automatically, without manually logging into the DUT and triggering the upgrade

TC108 : DUT should work with slow FTP servers

TC107 : If DUT is unable to connect to the Configuration Server (FTP/HTTP/etc. server), it should use the configuration it last downloaded.

TC26 : RFC2833 DTMF send

TC27 : G.729ab and G.711u codec support

TC28 : 20 ms packetization time

TC30 : Ringback on outbound calls to PSTN

TC31 : Ringback on outbound calls to all other supported SIP devices

TC32 : Early media playback for calls to PSTN (e.g., for calls sent to announcement by PSTN but never connected)

TC33 : Early media playback for local calls (e.g., for calls to Sequential Ring in BroadWorks or Custom Ringback in other platforms)

TC34 : Proper handset, speakerphone, and external-headset operation

TC62 : TOS or DSCP value can be configured for signaling and for RTP.

TC63 : DUT generates RTCP for all RTP sessions.

TC95 : After SDP offer/answer, DUT uses its own preferred codec rather than the most-preferred codec in the SDP answer.

TC97 : DUT that supports G.729 can be configured to disable silence suppression

TC109 : DUT should support Multicast Paging that can be used with BroadWorks/Metaswitch

TC91 : DUT audio quality in both directions is OK in the presence of moderate to extreme electromagnetic interference (EMI)

TC35 : Acoustic echo cancellation or mitigation on handset and speakerphone

TC36 : Gain control for handset and speakerphone (to reduce talker loudness)

TC37 : Volume control to change loudness of remote party

TC38 : Proper and Working mute and un-mute operation

TC102 : DUT will cancel out far-end echo so the user of the DUT doesn’t hear himself.

TC45 : Change call to use external headset

TC55 : If there are more softkey options available than there are softkeys, then DUT should show a “More…” button to get to the other softkey options.

TC58 : DUT can access and use vendor’s demo XML applications via the Internet when the URL is specified as a hostname and not an IP address.

TC61 : Use one default Services Application on phones for which no device-specific configuration has been generated, and a different default Services Application on phones for which a device configuration has been generated.

TC65 : If DUT supports a sidecar, the buttons can be assigned to new lines or programmable as softkey actions, including dialing BroadWorks/Metaswitch feature codes

TC66 : If DUT supports a sidecar, the buttons behave like buttons built-in to the phone.

TC83 : If DUT works with two sidecars, any button on any sidecar should be assignable to line registrations or programmable hotkeys on the sidecars.

TC92 : Softkeys should be programmable to access a URL, speed dial a number or Broadworks/Metaswitch feature code.

TC96 : DUT should be configurable to strip leading digits in the dial plan.

TC99 : DUT can dial feature codes that begin with a pound character; e.g., “#58”

TC100 : DUT can configure BroadWorks/Metaswitch call park and call-retrieve to softkeys

TC101 : DUT can be configured to disable the Do-Not-Disturb button on the phone

Beyond the 152

Of course, some platforms are going to offer more features. So be on the lookout for:

  • Video Conferencing
  • Video Calling and  Video Voicemail
  • Call Center Login/Logout
  • User-Activated Centralized Call Recording (e.g., SIPREC activation)
  • Phone-Based Call Recording

BroadWorks calls it “URL Dialing”: calling from your hosted PBX VoIP phone or SIP Trunking device to a random SIP URI. sip neon signLately, Polycom has been handing out SIP URIs and inviting people to test out their video bridges. Let’s say you want to call to sip:1234@opensips.org — how should it work?

Most VoIP services providers — such as those built on BroadWorks and Metaswitch — don’t allow calls from their subscribers to sip:1234@opensips.org to go through. How do you send in a SIP URI complete with domain anyway? Most users just think of dialing telephone numbers. And maybe extensions. Oh, and feature codes like *67. But definitely not “sip:lindsey@e-c-group.com”.

If you’re going to send it from the SBC, one big problem with allowing arbitrary outbound access to the Internet is that you have to allow arbitrary inbound SIP and RTP from the Internet. It’s hard to predict in advance where you’re going to be getting SIP from, and so it’s really hard to make appropriate session-agent or access-control statements to protect the SBC against CPU overload. Auto-blacklisting (such as “access-control-trust-level low” on the Oracle/Acme Packet SBC) can help some here though.

Option 1: Punt on Security, NAT Traversal, Billing, Support, etc.

The easiest option is just a separate button on a Polycom that sends the call where-ever on the Internet you want: of course  this doesn’t solve every problem. You’ve got NAT traversal. And your phones might not even have Internet access. But for a certain class of situations, this might get you what  you want. This is how I “normally” do it: direct from my Polycom, or more likely, EyeBeam.

Option 2:  SIP URI Calling to a few specific cases

If you just have a few specific cases, then you can pretty readily set them up as BroadWorks AS Identity/Device Profiles; that actually does allow a specific domain and an outbound proxy, which you could set to be the SBC.  This doesn’t require any setup on the Network Server, and it could allow the SBC to do the DNS lookups.

Option 3: Arbitrary dialing with DNS Server Support

But let’s say you can get OK with the security issues, and you need end users to make call to any SIP URI you want — including NAT traversal support and the SBC security, and BroadWorks/Metaswitch CDRs, etc. E.g., you want a polycom user to be able to type in a SIP URI on their desk phone and have it work as long as the SIP URI is valid.
To do this with BroadWorks, I’d have to resort to a special DNS server configuration that returned SRV records. Any time the AS/CFS does and SRV query for a random domain, the DNS server would respond with an SRV record sending the traffic to the  right interface on the SBC. Then the SBC would do the *true* DNS lookups and route the request across the Internets.

 

High Speed SIP Trunking with Metaswitch and Acme Packet

 

Metaswitch and Oracle Communications (formerly Acme Packet) would love to own each other’s customers; and many service providers own both.

This design shows how the two can be combined to make a scalable, high-performance SIP termination platform appropriate for outbound call centers.

High-performance call termination can be a challenge; many conventional systems, rich in SIP trunking features, aren’t optimized for customers that each need 50 calls/second (cps).

Scenario

  • Need for extremely high speed SIP termination, e.g., for large outbound call centers.
  • Oracle Acme Packet 4500 SBCs
  • Metaswitch CFS and MG3510 TDM VoIP to PSTN gateways
  • Service Provider has rich TDM and SS7 connectivity to various tandems on the PSTN
  • Geographically Distributed
  • Customer required to participate in scaling the traffic across multiple sites. This is the approach taken by all the major carriers for high-speed termination.

Key Design Features

  • Geographically Distributed System. The SIP trunk does not terminate to a single location, but rather to multiple locations.
  • The SBCs have their own failover capability, so that if the local Metaswitch CFS/MG3510 platform is overloaded, the SBCs have overflow routes to other carriers via SIP.
  • Exploits the fantastic capacity of the Metaswitch CFS and MG3510s.

Other Cool features

  • Each SBC is configured to limit the volume of traffic the customer may offer. For example, a customer that wants guaranteed no more than 50 CPS may be limited to 25 CPS at each of two sites. (For N+1 redundancy, add another site.)
  • We exploit the high performance of the Metaswitch CFS for call termination. These boxes are incredibly efficient at routing calls.
  • Calls are terminated to Metaswitch MG3510 TDM gateways. (Metaswitch now sells other models using their new CH6050 ATCA chassis, but there are many MG3510s in the field doing great work.) Each MG3510 has very high capacity, estimated here to be around 180 cps.
  • No one ordinary  64 kbps SS7 linkset can keep up with the total workload, so the MG3510s need multiple SS7 linksets.

Click to open the diagram for the full-sized version.