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.

 

1. IntroductionImage

Customers want quality voice and video. This can be readily provided using engineered links — i.e., paths that prioritize, reserve, or otherwise guarantee that the real-time voice and video packets will be delivered within the required timing constraints. But because of the wonderful cost reductions of Internet bandwidth, customers would prefer to get the quality voice and video services across the Internet, and not be forced to buy a special link to get that quality. Expecting the public Internet to provide adequate quality to make VoIP work reliably is an unreasonable expectation. This topic always reminds of the George Barnard Shaw quote:

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.

At SIP Forum’s SIPNOC 2014, we held a BoF “Birds of a Feather” session and Google Hangout to discuss ways to make Voice and Video via the Internet have better quality. We also had a conversation on the VoiceOps mailing list about this subject. The notes below reflect the comments made by folks in both fora.

2. Terminology

“Customer” refers to the customer of the ITSP. “CPE” (Customer Premise Equipment) refers to equipment installed a customer’s site. In the context of this discussion, all CPE is for use exclusively by the Customer at whose site it is hosted. “ISP” refers to Internet Service Providers. In this context, both the ITSP and the Customer purchase service from an ISP to connect to the Internet and thereby communicate with one another over the Internet. “ITSP” refers to an “Internet Telephony Service Provider”; but in general it’s any provider of Real Time, Interactive, N-way (N>1), Human media sessions. “OTT” (Over the Top) and “BYOB” (Bring Your Own Broadband) refer to a method of delivering servie where connection between the ITSP and the Customer is done over the public Internet, as opposed to a link where guarantees of performance are provided.

3. Miscellaneous Observations

3.1. Some methods of improving the media experience across the Internet are going to be more expensive than others. Some are thus going to be most applicable to larger customer sites, while others can be efficiently applied even to individual users/customers. 3.2. One major OTT/BYOB carrier reported seeing that some major companies (apparently ISPs) appears to be de-prioritizing VoIP traffic, making it work worse than typical IP traffic. 3.3. The techniques discussed here should apply well to Residential, Hosted PBX, and also to IP NNI (Network-to-Network Interconnections).

4. Detection methods

4.1. Individual Calls

4.1.1. RTCP or RTCP-XR received from individual calls 4.1.2. Monitoring of packets via a box in the middle (e.g., ITSP Border Element / SBC, or CPE edge device) 4.1.3. RTCP Extended data sent via SIP

4.2. Customer Sites

4.2.1. ICMP ping of customer all sites to detect which customer sites are having problems (and by extension, which customers’ ISPs are having problems). 4.2.2. Test calls to the customer site, e.g., to a loopback function

5. Quality Improvement Techniques

5.1. Involving multiple ISPs

5.1.1. Multiple ISPs or IP Peering Points at ITSP

5.1.1.1. Maximum number to increase number of options to reach customers. 5.1.1.2. Ability to manually tune routing to an ITSP customer that has a static public IP address, to avoid a particular ISP that is having problems. Example: End customer is on ISP 3. ITPS uses ISP 3 and ISP 3. Dispute or routing problem between ISP 3 and ISP 1 causes poor performance. So ITSP changes routing so that traffic destined to customer always exits ITSP network via ISP 2. 5.1.1.3. Advertise smaller blocks of IP space with BGP path preferences to control how customers’ traffic enters the network; i.e., try to groom all VoIP traffic to enter on the ITSP’s via the better ISP du jour. 5.1.1.4. On the ITSP border elements (e.g., SBC) assign different IP addresses that route in exclusively via a single ISP. E.g., SBC has customer-facing IP 1 that is only advertised via ISP 1, and a separate customer-facing IP 2 that is advertised only via ISP 2. Then configure Customer A SIP CPE to REGISTER via either IP 1, with SRV failover to IP 4. Then for Customer B, it may be better for them to register via IP 2 with failover to IP 1. 5.1.2. Multiple ISPs at Customer Premise. Use one ISP as a preferred option at the customer premise, then failover to another if the first one is too degraded as measured by SLA monitoring in the CPE router.

5.2. Codecs

5.2.1. Traditional codecs

5.2.2.1. G.729 instead of G.722 or G.711, simply to reduce the bandwidth required.

5.2.2. Adaptive Codecs

5.2.2.1. AMR / AMR-WB. Popular with vendors to implement, but relatively expensive because of Intellectual Property Fees. 5.2.2.2. Opus. Generally considered equal or superior to AMR-WB, but newer and thought to be considered immature by vendors.

5.2.3. Media Transport tricks.

5.2.3.1. Packetization Time (ptime) changes. It *might* be possible to reduce packet loss by reducing the packets/second rate of a media stream, but any reduction in packet loss will bring a proportionate increase in payload delivery. Much of the equipment in use won’t support ptime != 20 ms. 5.2.3.2. Media over TCP. WebRTC includes Media over TCP. There are studies showing that media over TCP, e.g., in TCP-based VPNs, improve something. But this probably means that jitter buffers are maximized. The group’s outspoken views are that that using today’s codecs over TCP is likely to make delay much worse. [http://www.voip-info.org/wiki/view/VOIP+and+VPN] claims that a study by Sirrix (a German security firm) reported no ill effects of VPNs on VoIP, but the study is no longer online. 5.3. Changing call path mid-call. Detect the problem (e.g., via RTCP) then re-INVITE to change the media flow to another IP address that uses a different routing path from the customer.

5.4. Customer Premise Equipment

5.4.1. Use a device at Customer Premise that can prioritize Voice traffic as it exits the VoIP CPE going toward PE router. This can be done with an application-aware device (SIP ALG) or via DSCP marking and prioritization. 5.4.2. Use a device at Customer Premise that can manage the PE-to-CE (ITSP to CPE) TCP flows to ensure that TCP flows slow down enough to allow the RTP flows. This likely requires an ALG, or, at least, a device that can recognize the distinct RTP flows that it is trying to protect.

5.5. Traditional QoS

5.5.1. Use QoS prioritization in the core of the network. 5.5.2. Use QoS prioritization at the customer premise, even though the link between ITSP and Customer is not protected. And use a QoS policy at the customer premise that matches what’s in use in the core. 5.5.3. Strip DSCP markings as packets arrive from untrusted networks, i.e., ISPs and customer sites outside your control.

5.6. Miscellaneous Recommendations.

5.6.1. Avoid messing with the media as much as possible; in particular minimize codec conversions. 5.6.2. Stay on the same network end-to-end, whenever possible. E.g., if you have customers that connect to you using Comcast at their customer premise, then try to connect the ITSP border element to Comcast.

6. Contributors

Thanks for contributions in this discussion go to: Alex Balashov (Everiste Systems), Chris Boyd (Gizmo Partners), Chris Brown (ACS Alaska), Frank Bulk (Premier Communications), Ryan Delgrosso, Jim Gast (TDS Telecom), Gavin Henry (SureVoIP), Jesse Howard (Shoretel), Faisal Imtiaz (Snappy Telecom), Eric Jastak, Brandon Lehmann, (BitRadius), Mark R Lindsey (ECG), Anthony Orlando, Gernot Scheichl (Edgewater Networks), Dan York, as well as other anonymous participants at SIPNOC and on VoiceOps.