Acme Packet – “no Redundancy Protocol Process Running”

Symptoms of the Issue:

While setting up an SBC in my lab today I came across an error that I’ve encountered a few times in the past. The error message is “no Redundancy Protocol Process Running” which appears when running a “show health” command.

Command : Show health

Acme packet redundancy troubleshooting

What’s frustrating about this error is that the redundancy config is enabled when you review the redundancy-config section ( show configuration redundancy-config ). 

Command : Show configuration redundancy-config

Troubleshooting:

When troubleshooting anything related to redundancy on the Acme Packet / Oracle SBCs, I’ve found the best approach is to go straight to the logs. Specifically “log.berpd”.

Command : Show logfile log.berpd

acme-packet-solving-redundancy-issues

After reviewing the output I can see that this SBC doesn’t have a hostname that matches what I have built as peer-name within the redundancy config.  There are two locations to create a hostname on the Acme Packet SBCs. One option is to create the name under “config t > system > system-config > hostname”. If you enter the hostname here followed by a save / activate / reboot the error will persist.

 

Resolution

Where the hostname needs to be entered with within the bootparam settings.

troubleshooting-acme-packet-redundancy-issues

  1. Navigate to Enable > Conf t > boot
  2. You will be presented with a line asking for the “Boot File”. Press enter to the skip to the next line.
  3. Keep pressing Enter until you arrive on the Target Name line.
  4. Enter the hostname that you used when building out the redundancy peer-name.
  5. Keep pressing Enter until  you are out of the boot param menu.
  6. Perform a Save / Active.
  7. Reboot the SBC

After rebooting you should be able to run a “show health” and see that redundancy is running.

 

 

How to determine VOIP Bandwidth

I’ve come across many scenarios where people assume that VOIP calls consume 64kbps per call. They instantly assume that because the payload of a codec such as G.711u is 64k. While the payload IS 64k for a G.711u call there are other factors in play. If you want to properly calculate the VOIP bandwidth of a single call, follow these steps.

1. Determine the bandwidth for the audio codec.

For the sake of simplicity, let’s continue using G.711u as the codec. We do not send one massive 64k packet once per seconds in a call. That would cause some serious issues with audio quality. Instead each packet is going to contain a small amount of audio. The default for most codecs and deployment scenarios is 20ms. This can be adjusted, however it’s limited by the SIP stack and /or DSPs on your system

To find out how big each packet is we do the following equation.

Bytes Per Packet = (Sample Size * Codec Bandwidth) / 8

So we have (.20 * 64,000) /8

This equals 160 bytes.

2. Determine the datalink, network and transport overhead.

Depending on the layer 2 network (datalink) we are going to have different amounts of overhead.

Ethernet = 20 byes
Frame Relay = 6 bytes
PPP = 6 bytes

In terms of the network and transport overhead we can assume that IP, UDP, and RTP will always be used.
IP = 20 bytes
UDP = 8 bytes
RTP = 12 bytes

We will make the assumption that layer 2 on this call is ethernet.

160 + 20 + 40 = 220 bytes

3. Add optional overhead.

Packets often traverse a VPN of some sort. This adds additional bandwidth.

GRE = 24 bytes
MPLS = 4 bytes
IPSEC = 57 bytes

Let’s assume that we have an MPLS connection in place.

220 + 4 = 224 bytes

4. Add it up.

We know that each packet consumes 224 bytes. Remember how we used 20ms as the amount of audio per packet? If we use 20ms, how many packets per second are being sent. If 1 seconds == 1000ms, then 1000 /20 = 50.

We will send 50 packets per second.

224 * 50 = 11200 bytes per second.

We normally don’t look at bandwidth as bytes per second. We need to convert this to bits by simply multiplying by 8.

11200 * 8 = 89,600 bits.

With this scenario, each call will consume almost 90kbps. Had this calculation been made as 64k per call we could quickly run into capacity issues.

Want to run your own calculations? Here are the payload sizes of a few common codecs:

G711 = 64,000
ILBC = 15,200
G729 = 8,000
G.726 = 32,000
G.729a = 8,000
G.728 = 16,000
G.722 = 64,000 (Note – this can also be 56,000 or 48,000 depending on the set bitrate)

Here’s a scenario for you to run through.

Codec :G.729a (8,000)
Sample Size : Each packet has 20 ms of audio
Layer 2 : Ethernet circuit between device A and Device B
Extra Overhead: MPLS and IPSEC are used across the link

Write your answer in the below comment box.

Is your Polycom Phone under attack?

Anyone that has worked in telecom long enough has been hit by a SIP scanner at some point in time.

For people in NOC / Support teams, they often have a customer open a ticket where the call goes like this:

Caller : “My phone is randomly ringing and will not stop.”

Tech Support : “Let me look at the logs.”

Tech Support reviews the logs, while the customer enjoys hold music that isn’t even fit for an elevator. 

10 minutes later

Tech Support : “I’m happy to report that we are not sending any calls to your device during that time. Your ticket number is 222444555, have a great day”

A few days later the caller is back on the phone. They are furious as the issue is still happening. The support team doesn’t see the call in the logs, as it didn’t traverse through the VoIP providers core.

Thankfully for those with Polycom phones, you can make a change to the device’s XML file to block unsolicited INVITES.

All you need is this:

< voIpProt.SIP.requestValidation.1.request=”INVITE” voIpProt.SIP.requestValidation.1.method=”source”/>

Once applied, if the phone receives an INVITE from a device other than the IP of reg.1.server.address, it will reject the request with a SIP 400 BAD REQUEST.

Now instead of the user experiencing a phone that rings non-stop, they see and hear nothing.

Bad Guy – Blocked!

 

Research: I tested this with a VVX 500 (5.2 software)  and a SIP testing tool know as SIPP. I sent over 50 calls per second to the device while it was on an active call. During the active call I did not experience any audio issues.

When the call was disconnected, I did experience a phone that acted “slower” than normal to return to the home screen. Going off hook also introduced about a 1 second delay before presenting dial tone.

 

 

 

 

 

 

 

 

Can’t connect with Broadworks Deployment Studio? Read this to save an hour of your life.

I had an issue that drove me insane today. While attempting to push a few changes to the Broadworks Call Center App. I was adamant that I had entered the correct values on the “Deployment” tab, yet I kept receiving this error:
(all IPs, domains and usernames have been changed)

 

Timeout occurred waiting for response from server. Please contact your service provider if this problem persists.
Timeout occurred waiting for response from server. Please contact your service provider if this problem persists.

 

This error didn’t seem like it was telling the truth, so I went to the source : The OCSLog file on the server hosting OCI.

 

2015.10.26 16:29:06:340 MST | Info | OpenClientServer

Received message from client on unsecure socket 13143 | Host:Port 1.1.1.1:62253/1.1.1.1 | Local Port 2208

2015.10.26 16:29:06:340 MST | Info | OpenClientServer

Received message from client on unsecure socket 13143 | Host:Port 1.1.1.1:62253/1.1.1.1 | Local Port 2208:


192.168.154.75--4009030666984229966

 adminusername

2015.10.26 16:29:06:348 MST | Info | OpenClientServer

Getting PROV serving AS info from NS for user adminusername.

2015.10.26 16:29:06:348 MST | Info | OpenClientServer

http://10.10.10.71:80/servlet/LocateUser?url=adminusername%40my.default.domain&returnCompatibleXSP=false&callPRequest=false

2015.10.26 16:29:06:348 MST | FieldDebug | Generic

HTTP connected...

2015.10.26 16:29:06:351 MST | Info | OpenClientServer

Getting response from NS (10.10.10.71):


 

2015.10.26 20:51:26:696 MST | Info | OpenClientServer

Sending OCI message to client using connection unsecure socket 13167 | Host:Port 1.1.1.1:55681/1.1.1.1 | Local Port 2208
192.168.16.118--6954723538114549563
 [Error 5401] User is not found on Network Server.

[Error 5401] User is not found on Network Server.

 

Ok… no big deal, I can add the username in question. I logged into the NS and added the user to “NS_CLI/SubscriberMgmt/Administrator/User>”.

NS_CLI/SubscriberMgmt/Administrator/User> get

Administrator ID  =  adminusername@my.default.domain
  Name            =  Name, Admin
  Access Level    =  System Provider

Tried it again, the same error punched me in the face.

I took a wild guess and add the user to ” NS_CLI/SubscriberMgmt/Administrator/HostingNEUser>”

NS_CLI/SubscriberMgmt/Administrator/HostingNEUser> get bwas userID adminusername@my.default.domain
          Administrator ID  Subscriber Maintenance Partition
============================================================
  adminusername@my.default.domain

1 entry found.

SUCCESS! This finally let me in. Hopefully this saves someone else a ridiculous amount of troubleshooting time.

Vonage to Acquire iCore Networks, Inc. to Accelerate Its Unified Communications Strategy

http://pr.vonage.com/releasedetail.cfm?ReleaseID=928298

Acquisition Expands Vonage’s UCaaS Leadership, Creates Significantly Greater Scale and Increases Up-Market Sales and Product Set

HOLMDEL, N.J., Aug. 20, 2015 /PRNewswire/ — Vonage Holdings Corp. (NYSE: VG) (“the Company”), a leading provider of cloud communications services for businesses and consumers, has entered into a definitive agreement to acquire privately-held iCoreNetworks, Inc. (“iCore”), a premier provider of Unified Communications-as-a-Service (UCaaS) for businesses, for $92 million.

“iCore is an excellent strategic fit and a natural complement to Vonage’s rapidly expanding UCaaS business. This acquisition will deepen our penetration at the higher end of the business market and further strengthen our industry leadership,” said Alan Masarek, Vonage Chief Executive Officer. “iCore has a proven track record of delivering the innovative UCaaS solutions required by mid-market and enterprise companies, and has been particularly successful combining hosted communications with complementary cloud services to create a robust unified communications experience.”

Mr. Masarek continued, “Our strategy is to serve businesses of any size via a multi-channel distribution approach. With the addition of iCore, Vonage will have what we believe is the largest sales force in the UCaaS market, addressing mid-market and enterprise companies through a Field Sales organization that sells directly to customers and a Channel Sales organization that supports our extensive nationwide network of indirect channel partners. Vonage serves the SMB market through a highly-successful Inside Sales team augmented with Online sales. Combined with iCore, we believe we will have the broadest multi-channel distribution platform in our industry and are ideally positioned to serve the full spectrum of the UCaaS market, from SMB to mid-market to enterprise.”

Mr. Masarek concluded, “We look forward to welcoming the iCore team into the Vonage family and to further enhancing the experience of iCore’s customers with Vonage’s award-winning customer service, provisioning expertise, national MPLS network, and dedicated focus on innovation.”

“In less than two years, Vonage has become the fastest-growing provider of UCaaS solutions for business, and becoming part of Vonage will instantly put iCore at the forefront of this growth,” said Stephen G. Canton, CEO, Chairman and Founder of iCore. “I couldn’t be more excited that iCore’s employees and customers will now benefit from Vonage’s strength, scale and leadership position in the industry.”

Significantly Expands Field Sales Force and Accelerates Move Up-Market

iCore sells its solutions primarily through its large, direct field sales force, adding significant scale and a national footprint to Vonage’s existing sales force. iCore supports more than 85,000 customer seats, with monthly ARPU per customer of more than $4,000, and derives more than 60% of its revenue from customers with 100 or more seats. Monthly revenue churn is less than one percent as a result of three-year contracts that include Quality of Service (“QoS”) guarantees.

Complementary Technology Platform

iCore offers a broad range of voice, video, mobile and collaboration services to address the evolving needs of businesses. It leverages the same BroadSoft BroadWorks call processing platform used by Vonage, resulting in ease of integration for iCore’s customers. iCore has a subset of customers running on BroadSoft’s M6 platform. In order to meet the varying needs of customers, iCore offers a comprehensive Microsoft Lync-as-a-Service solution. Finally, iCore also offers a full range of complementary cloud services, such as Infrastructure as a Service (IaaS), virtual desktop, and hosted Microsoft Exchange.

Transaction Terms, Financing and Anticipated Synergies

Under the terms of the Merger Agreement, which has been unanimously approved by the boards of directors of Vonage and iCore, shareholders of iCore will receive $92 million in cash, subject to customary closing adjustments. A portion of the purchase price will be deposited into escrow to secure certain indemnification rights under the merger agreement. The purchase price represents approximately 1.3 times estimated 2015 iCore revenues. The transaction is expected to close by the end of the third quarter of 2015, subject to customary closing conditions and regulatory approvals.

Vonage is financing the transaction through cash from its balance sheet and from the Company’s revolving credit facility, resulting in pro forma net debt to adjusted LTM EBITDA of approximately 1.5 times as of June 30, 2015.

Given the similarities of the businesses and their common technology, Vonage expects to achieve synergies in network operations, technology used to service customers, and various operating expenses. Annual recurring cost synergies are expected to exceed$5 million in 2016.

Updated 2015 Guidance

The Company is updating its 2015 revenue guidance to include the impact of the iCore acquisition.  Vonage expects total 2015 GAAP revenue to be in the range of $885 million to $892 million. This revenue guidance assumes that the transaction closes bySeptember 30, 2015 and excludes iCore’s deferred revenue due to purchase accounting rules. The Company now expects year-over-year 2015 Vonage Business pro-forma organic revenue growth, as if the Company owned Telesphere, Simple Signal and iCore for all comparable periods, to be approximately 37 percent. The Company continues to expect adjusted EBITDA to be at least $135 million and capital expenditures to be approximately $30 million.

About Vonage

Vonage (NYSE: VG) is a leading provider of cloud communications services for businesses and consumers. The Company provides a robust suite of feature-rich business and residential communication solutions that offer flexibility, portability and ease-of-use across multiple devices designed to meet the needs of a wide range of customers. Vonage’s portfolio of business products covers the full spectrum of business communications needs, serving single-person companies to those with thousands of employees spread over multiple locations. Vonage provides bring-your-own-broadband (BYOB) cloud products and those that offer carrier-grade reliability and Quality of Service (QoS) across BYOB options and the Company’s private, national MPLS IP network. For more information, visit www.vonage.com.  Vonage was advised by Pacific Crest Securities, a division of KeyBanc Capital Markets, and Weil, Gotshal & Manges LLP.

About iCore Networks

iCore’s mission is to radically improve the way people work by bringing customized Unified Communications and Cloud services together for an all-in-one experience. Reinventing the modern office, iCore replaces outdated PBX systems and eliminates capital costs. iCore drives performance with flexible products, expert consulting, dedicated account teams, and 24/7/365 customer support – giving rise to agile growth opportunities and untethered employees. For more information, please visit www.icore.com.  iCore was advised by Wells Fargo Securities, LLC, as exclusive financial advisor, and Foley & Lardner LLP.

Safe Harbor Statement
This press release contains forward-looking statements within the meaning of the safe harbor provisions of the United States Private Securities Litigation Reform Act of 1995. Forward-looking statements include, but are not limited to: (i) statements about the benefits of the Merger; (ii) future financial and operating results following the Merger; (iii) the combined company’s plans, objectives, expectations and intentions with respect to future operations, products and services; (iv) the competitive position and opportunities of the combined company; (v) the impact of the Merger on the market for the combined company’s products and services; (vi) the timing of the completion of the Merger, and (vii) other statements that are not historical facts or information, that constitute forward-looking statements for purposes of the safe harbor provisions under The Private Securities Litigation Reform Act of 1995. In addition, words such as “plan,” “anticipate,” “believe,” “estimate,” “expect,” “intend,” “will,” “should,” and similar expressions are intended to identify such forward-looking statements. Such forward-looking statements are based upon the current beliefs and expectations of Vonage’s management and are inherently subject to significant business, economic and competitive uncertainties and contingencies, many of which are difficult to predict and generally beyond the control of Vonage. The risks and uncertainties that could cause our results to differ materially from those expressed or implied by such forward-looking statements include, but are not limited to: (a) risks related to the integration of iCore into Vonage and the anticipated future benefits resulting from the acquisition of iCore; (b) Vonage’s or the combined company’s ability to react to trends and challenges in our business and the markets in which we operate; (c) Vonage’s or the combined company’s ability to anticipate market needs or develop new or enhanced products to meet those needs; (d) as the UCaaS market evolves, Vonage’s or the combined company’s ability to compete with companies that do not currently compete in the UCaaS market; (e) the adoption rate of Vonage’s or the combined company’s products; (f) Vonage’s or the combined company’s ability to establish and maintain successful relationships with our distribution partners; (g) our ability to compete in our industry; (h) fluctuations in demand, sales cycles and prices for Vonage’s or the combined company’s products and services; (i) shortages or price fluctuations in Vonage’s or the combined company’s supply chain; (j)Vonage’s or the combined company’s ability to protect intellectual property rights; (k) general political, economic and market conditions and events; (l) the expense and impact of legal proceedings; and (m) other factors that are set forth in the “Risk Factors” section and other sections of Vonage’s Annual Report on Form 10-K for the year ended December 31, 2014, in the Company’s Quarterly Reports on Form 10-Q and Current Reports on Form 8-K.  While the Company may elect to update forward-looking statements at some point in the future, the Company specifically disclaims any obligation to do so, and therefore, you should not rely on these forward-looking statements as representing the Company’s views as of any date subsequent to today. Vonage Holdings Corp. is headquartered in Holmdel, New Jersey. Vonage® is a registered trademark of Vonage Marketing LLC, owned by Vonage America Inc.

To follow Vonage on Twitter, please visit www.twitter.com/vonage. To become a fan on Facebook, go to www.facebook.com/vonage. To subscribe on YouTube, visit www.youtube.com/vonage.

(vg-f)

To view the original version on PR Newswire, visit:http://www.prnewswire.com/news-releases/vonage-to-acquire-icore-networks-inc-to-accelerate-its-unified-communications-strategy-300131208.html

SOURCE Vonage

News Provided by Acquire Media

Vonage Holdings Corp. to Acquire Telesphere Networks Ltd.

Interesting day! I’ve been an employee of Telesphere for 4.5 years. I’m excited to see where this takes us.

Article Acquired from :
http://www.prnewswire.com/news-releases/vonage-holdings-corp-to-acquire-telesphere-networks-ltd-281598821.html

HOLMDEL, N.J., Nov. 5, 2014 /PRNewswire/ — Vonage Holdings Corp. (NYSE: VG) has entered into a definitive agreement to acquire privately-held Telesphere Networks Ltd., an industry-leading provider of Unified Communications-as-a-Service (UCaaS) solutions to larger enterprises in the small and medium business (SMB) sector, for $114 million in cash and stock.

Telesphere offers a comprehensive suite of cloud voice and UCaaS services, including advanced call center solutions, collaboration, mobile office and HD multi-point video conferencing. Telesphere has provided cloud communications since 2006 and has built a national, cloud platform that is especially well suited to address the needs of larger SMBs with regionally distributed offices.

“A year after Vonage moved into the rapidly growing UCaaS market, we are substantially expanding our presence within the sector through the Telesphere acquisition. This is an important next step in the continued execution of the Company’s long-term growth strategy,” said Marc Lefar, Chief Executive Officer of Vonage. “As we have demonstrated, the use of Vonage’s scale, brand, balance sheet and cash generation to invest in the acquisition of growth businesses has been very successful. Vonage Business Solutions’ annual revenue growth has accelerated from 38% to 52% in a year, and we are confident in our ability to accelerate growth at Telesphere as we bring it under the Vonage umbrella.”

Combined Business with Leading Scale in UCaaS

Telesphere is highly complementary to Vonage Business Solutions (“VBS”). With the addition of Telesphere, Vonage will now be able to provide a comprehensive and compelling range of cloud-based solutions to address the needs of a wide range of enterprises.

Telesphere’s average seat size per customer is more than 40, and average monthly recurring revenue per customer is nearly $3,000. Telesphere’s 2014 revenues are expected to be approximately $40 million, with more than $50 million of revenue already under contract for 2015. Vonage will pay a multiple that is two times or less estimated 2015 revenues.

Recognized for its strong technical and operational expertise in UCaaS, Telesphere was ranked as a top provider in Gartner’s 2014 Magic Quadrant for UCaaS. Similarly, Telesphere’s auto-provisioning and monitoring tools, critical for successful installations and ongoing management at larger multi-location businesses, received Internet Telephony magazine’s 2012 BSS/OSS Excellence Awards by TMC.

Clark Peterson, CEO of Telesphere, commented, “Vonage already has a strong leadership position in hosted cloud communications and SaaS solutions through Vonage Business Solutions. Our two businesses complement each other well and will fortify Vonage’s scale in the high growth market for unified communications. As UCaaS continues to evolve and adoption grows among businesses of all sizes, Vonage and Telesphere will be at the forefront of this growth. I am very excited about our future together.”

Mr. Peterson will join Vonage as President of Telesphere, a Vonage company, upon closing. Mr. Peterson has more than 25 years of experience in the communications industry and currently serves as Chairman of the Cloud Communications Alliance.

Alan Masarek, who will become the Chief Executive Officer of Vonage effective November 6, commented, “Through the acquisition of Telesphere, Vonage is well positioned to provide an expanding range of unified communications services beyond those offered today, and to further penetrate the large and rapidly growing UCaaS market. We welcome the Telesphere team to the Vonage family and look forward to working together on our mission to become the premier provider of communications services for consumers and businesses.”

Transaction Terms and Financing

Under the agreement, Telesphere shareholders will receive total consideration of $114 million comprised of approximately $91 million in cash and approximately 6.86 million shares in Vonage common stock representing $23 million, subject to customary closing adjustments and indemnity escrow arrangements. The transaction is expected to close in 2014, pending regulatory approvals. Cash consideration for the transaction will be financed through available cash and Vonage’s existing $125 million credit facility.

Evercore provided a fairness opinion and served as financial advisor and Weil Gotshal & Manges as legal counsel to Vonage in connection with this transaction. Wells Fargo Securities, LLC served as the financial advisor and Snell & Wilmer as the legal counsel to Telesphere.

Conference Call

Vonage will discuss further details of this transaction at 10:00 AM Eastern Time on November 5, 2014 during the Company’s Third Quarter 2014 earnings call. To participate, please dial (877) 359-9508 approximately 10 minutes prior to the call. International callers should dial (224) 357-2393.

The webcast will also be broadcast live through Vonage’s Investor Relations website at http://ir.vonage.com. Windows Media Player or RealPlayer is required to listen to this webcast. A replay of the call and webcast will be available shortly after the conclusion of the call through November 12, 2014, and may be accessed through Vonage’s Investor Relations website at http://ir.vonage.com or by dialing (855) 859-2056. International callers should dial (404) 537-3406. The replay passcode is: 20017524.

Safe Harbor Statement

This press release contains forward-looking statements within the meaning of the safe harbor provisions of the United States Private Securities Litigation Reform Act of 1995. Forward-looking statements include, but are not limited to: (i) statements about the benefits of the acquisition; (ii) future financial and operating results following the acquisition including the amount of revenue expected to be generated by Telesphere for the remainder of 2014 and in 2015; (iii) the combined company’s plans, objectives, expectations and intentions with respect to future operations, products and services; (iv) the competitive position and opportunities of the combined company; (v) the impact of the acquisition on the market for the combined company’s products and services; (vi) the timing of the completion of the acquisition and (vii) the planned completion of Vonage’s current share repurchase program. In addition, words such as “anticipate,” “believe,” “budget,” “could,” “estimate,” “expect,” “forecast,” “intend,” “may,” “plan,” “potential,” “predict,” “project,” “should,” “will” and similar expressions are intended to identify such forward-looking statements. Such forward-looking statements are based upon the current beliefs and expectations of Vonage’s management and are inherently subject to significant business, economic and competitive uncertainties and contingencies, many of which are difficult to predict and generally beyond the control of Vonage. The risks and uncertainties that could cause our results to differ materially from those expressed or implied by such forward-looking statements include, but are not limited to: (a) risks related to the integration of Telesphere into Vonage and the anticipated future benefits resulting from the acquisition of Telesphere; (b) Vonage’s or the combined company’s ability to react to trends and challenges in our business and the markets in which we operate; (c) Vonage’s or the combined company’s ability to anticipate market needs or develop new or enhanced products to meet those needs; (d) the adoption rate of Vonage’s or the combined company’s products and services; (e) Vonage’s or the combined company’s ability to establish and maintain successful relationships with our distribution partners; (f) our ability to compete in our industry; (g) fluctuations in demand, sales cycles and prices for Vonage’s or the combined company’s products and services; (h) Vonage’s or the combined company’s ability to protect intellectual property rights; (i) general political, economic and market conditions and events; (j) the expense and impact of legal proceedings; and (k) other risks and uncertainties described more fully in Vonage’s documents filed with or furnished to the Securities and Exchange Commission. All forward-looking statements in this document are based on information available as of the date hereof, and Vonage assumes no obligation to update these forward-looking statements. Vonage reserves the right to modify future business or product plans at any time.

About Vonage

Vonage (NYSE: VG) is a leading provider of communications services connecting consumers and businesses through cloud-connected devices worldwide. Vonage provides a robust suite of feature-rich, residential and business communication solutions that offer flexibility, portability and ease-of-use for both landline and mobile phones. Vonage’s residential service is sold on the web (www.vonage.com) and through telesales and regional and national retailers, and its business service is sold through Vonage Business Solutions (www.vonagebusiness.com) telesales and channel partners.

Vonage Holdings Corp. is headquartered in Holmdel, New Jersey. Vonage® is a registered trademark of Vonage Marketing LLC, owned by Vonage America Inc.

To follow Vonage on Twitter, please visit www.twitter.com/vonage. To become a fan on Facebook, go to www.facebook.com/vonage. To subscribe on YouTube, visit www.youtube.com/vonage.

About Telesphere

Telesphere, based in Phoenix, Ariz., is a leading provider of business VoIP solutions nationwide. Telesphere offers carrier-grade performance and support for wireline and mobile devices to businesses over its private IP MPLS network, one of the largest in the nation. Telesphere’s cloud-based UCaaS services allow businesses of any size to enjoy all the latest voice, video, data and collaboration features of large enterprise systems without the costly investment of on-premise equipment.

SOURCE Vonage Holdings Corp.

Broadworks – How to Change a device from Proxy Addressing to Device Addressing

Please Note – This should be performed on your LAB only.

There have been many times where I am tasked to perform interop on a device lacking a Broadsoft Partner Config Guide (PCG). These scenarios are great fun as there are some options that you initially set that CANNOT be changed via BWCLI or the GUI. The main options that come to mind are:
Is this Device Addressing?
     Intelligent?
     Non-Intelligent?
Is this ‘Proxy Addressing’?
     Intelligent?
     Non-Intelligent?
I used to make a device type and hope that it would work as planned. If not, I would remove all of my config (usually trunk groups with 10 + test users) and start over on a new device type. Then one day I got sick of it!  I decided to poke around in the Database, and low and behold I found a solution.
1. From the AS (linux cli)  launch ‘ttisql <DSN-NAME>’. Note – Your DSN is probably named ‘AppServer’>
2. Perform a query for the device name in question :
 SELECT * from BWAS.DEVICE_TYPE WHERE DEVICE_TYPE = 'Cisco 36xx-Trunk' ; < 2401, Cisco 36xx-Trunk, N, -1, SIP                 , N, N, <NULL>, <NULL>, <NULL>, NONE      , <NULL> > 1 row found.
If you interested in more details (column names) you can perform a ‘describe’ on the table:
DESCRIBE  BWAS.DEVICE_TYPE  ; Table BWAS.DEVICE_TYPE: Columns: *DEVICE_TYPE_UID                 INTEGER NOT NULL DEVICE_TYPE                     VARCHAR (40) INLINE NOT NULL OBSOLETE_FLAG                   CHAR (1) NOT NULL NUM_PORTS                       INTEGER NOT NULL PROTOCOL_NAME                   CHAR (20) NOT NULL MONITORING_ENABLED_FLAG         CHAR (1) NOT NULL CPE_DEVICE_RESET_SUPPORTED      CHAR (1) CPE_SYSTEM_FILENAME             VARCHAR (256) NOT INLINE CPE_DEVICE_FILE_FORMAT          VARCHAR (256) NOT INLINE CPE_RESET_EVENT                 VARCHAR (256) NOT INLINE CPE_CONFIG_TYPE                 CHAR (10) CPE_BLANK_PARAM                 VARCHAR (40) INLINE 1 table found. (primary key columns are indicated with *)
3. At this point, you are primarily concerned with the DEVICE_TYPE_UID. In my example, it is ‘2401’. We can now look at all of the options associated with this device using the following query :
 
SELECT * from BWAS.DEVICE_OPTION where  DEVICE_TYPE_UID  = 2401 ;
con1: Command> select * from BWAS.DEVICE_OPTION where  DEVICE_TYPE_UID  = 2401 ; < 12904012, 2401, conferenceDevice, N > < 28573002, 2401, authenticationMode, enabled > < 46250484, 2401, e164Capable, N > < 29374604, 2401, forwardingOverride, N > < 90879096, 2401, intelligentDevice, Y > < 91040296, 2401, mobileDevice, N > < 16150412, 2401, mohDevice, N > < 49242892, 2401, pbxIntegration, N > < 83439424, 2401, registration, N > < 14534300, 2401, routeAdvance, N > < 70967144, 2401, staticRegistration, Y > < 16213366, 2401, supports3264Hold, N > < 97868544, 2401, trusted, N > < 45655300, 2401, useASAddressFlag, N > < 22684914, 2401, videoCapable, N > < 24849980, 2401, webBasedConfigURL,  > < 82896368, 2401, ringbackToneEarlyMediaSupport, rtp-session > < 81499856, 2401, authenticateRefer, Y > < 25194988, 2401, autoConfigSoftClient, N > < 32188506, 2401, mobilityManagerDevice, N > < 3381306, 2401, requiresBroadWorksDigitCollection, N > < 16195688, 2401, requiresBroadWorksCallWaitingTone, N > < 58551144, 2401, requiresMWISubscription, N > < 17414268, 2401, useHistoryInfoHeader, N > < 50192144, 2401, aocCapable, N > < 94991328, 2401, supportCallCenterMIMEType, N > < 46558876, 2401, trunkMode, user > < 75805096, 2401, addPCalledPartyId, N > < 66933524, 2401, supportIdentityInUpdateAndReInvite, N > < 56298980, 2401, unscreenedPresentationIdentityPolicy, profilePresentationIdentity > 30 rows found.
4.  Now you need to determine what you want to change.  The Signaling Type is currently ‘Intelligent Device Addressing’. Do you want this to be Intelligent Proxy Addressing ?  Change the ‘ useASAddressFlag’ value :
Command> UPDATE BWAS.DEVICE_OPTION set OPTION_VALUE='Y' where DEVICE_TYPE_UID  = 2401 and OPTION_NAME = 'useASAddressFlag';
Do you want to change this to a NON Intelligent device? Update the ‘intelligentDevice’ value :
UPDATE BWAS.DEVICE_OPTION set OPTION_VALUE='N' where DEVICE_TYPE_UID  = 2401 and OPTION_NAME = 'intelligentDevice';
As you can see, it is fairly easy to modify these values. I do stress – ONLY PERFORM THIS ON YOUR DEV/LAB ENVIRONMENT.

Broadworks XSI-Event webhooks

I started looking into webhooks for xsi-events updates. With Django, building a very basic hook took only a short amount of time!

First off, why would you use xsi-events? Xsi-events are used for notifcations of real-time events. This will allow you to monitor things like calls in queue, users on DND, and anything else found in the Receptionist or Call Center thin clients.

XSP servers have a test page built into them. You can find the URL in the XSI-events user guide from http://developers.broadsoft.com.

You can use the test page to trigger a subscription to an event. You can send the data as JSON or XML. You can also build something very easily with curl :


curl -u 'user@domain.net:password' -H "Content-Type: text/xml" -d @test.xml -X POST https://xsp.local/com.broadsoft.xsi-events/v2.0/enterprise/TEST/group/TEST-GROUP -v

 

This will require an Enterprise administrator credentials in the curl request.

Once you trigger this, the XSP will respond with POST request to the uri found in the XML file.

Now you need a way to handle this.

In your view.py file, you can build a very simple handler. Notice the csrf_exempt decorator. As the POST request will not send a csrf token, you will need a method to by pass this.

from django.core.context_processors import csrf
import callcenter.tools as ct

@csrf_exempt
def xsiEvents(request):
        if request.method == 'POST':
                data = ct.xml_xsi_ccqueue(request.body)
                return HttpResponse()
        if request.method  == 'GET' :
                return HttpResponse()

As you can see, when the request method is POST, Django will call another method for processing. I built a model where all updates matching certain criteria are stored. Yeah.. this could be better, however this is all in dev mode right now.

class callcenter_queue(models.Model):
        userId = models.CharField(max_length=100)
        externalApplicationId  = models.CharField(max_length=100)
        httpContact = models.URLField(max_length=100)
        targetId = models.CharField(max_length=100)
        eventData = models.CharField(max_length=100)
        callhalf = models.CharField(max_length=100)
        extTrackingId = models.CharField(max_length=100)
        addTime = models.CharField(max_length=50)
        acdName = models.CharField(max_length=100)

In the handler, I first parse the XSML. I turn turn various tags, text and attributes into dictionary keys and values.

I then update or delete the table (model) if the ‘eventData’ key matches certain criteria.

import xml.etree.ElementTree as ET
def xml_xsi_ccqueue(data):
        root = ET.fromstring(data)
        response = {}
        for child in root:
                if child.tag == '{http://schema.broadsoft.com/xsi}eventData' :
                        response[child.tag.replace('{http://schema.broadsoft.com/xsi}', '') ] = str(child.attrib)
                else:
                        response[child.tag.replace('{http://schema.broadsoft.com/xsi}', '') ] = child.text
                for sub in child:
                        response[sub.tag.replace('{http://schema.broadsoft.com/xsi}', '') ] = sub.text
                        for meta in sub:
                                response[meta.tag.replace('{http://schema.broadsoft.com/xsi}', '') ] = meta.text

        # Query for a extTrackingID that mathces the xsi-event POST
        if response['eventData'] == '{'{http://www.w3.org/2001/XMLSchema-instance}type': 'xsi:ACDCallAddedEvent'}':
               f.write('found eventData')
               xsi_update = callcenter_queue(
                        userId =  response['userId'],
                        externalApplicationId =  response['externalApplicationId'],
                        httpContact=  response['uri'],
                        targetId =  response['targetId'],
                        eventData =  response['eventData'],
                        callhalf =  response['callId'],
                        extTrackingId =  response['extTrackingId'],
                        addTime =  response['addTime'],
                        acdName =  response['acdName']
               )
               xsi_update.save()
               return response
        #if the call is answered, delete the event from the database
        if  'ACDCallAnsweredByAgentEvent' in response['eventData'] :
                try :
                        f.write('read to remove')
                        f.write( str(response['extTrackingId']))
                        xsi_update  = callcenter_queue.objects.get(extTrackingId = response['extTrackingId'] )
                        xsi_update.delete()
                except:
                        pass

        #if the caller bails out remove the call from queue
        if  'ACDCallAbandonedEvent' in response['eventData'] :
                try :
                        xsi_update  = callcenter_queue.objects.get(extTrackingId = response['extTrackingId'] )
                        xsi_update.delete()
                except:
                        pass

Now this is a very basic example of building a webhook for xsi-events. There’s a lot of code that I can clean up here, however it does function in a lab/dev environment.

 

 

=========

UPDATE 10/21/2014

=========

Here is a sample of the XML I use for this call:

<?xml version=”1.0″ encoding=”UTF-8″? >
<Subscription xmlns=”http://schema.broadsoft.com/xsi”  >
<targetIdType>https://xsp.local/com.broadsoft.xsi-events/v2.0/enterprise/$ENTERPRISE_NAME/group/$GROUP_NAME</targetIdType >
<event>Call Center Monitoring</event >
<expires>86400</expires>
<httpContact>
<uri>http://myserver.local/webhooks</uri >
</httpContact>
<applicationId>CUSTOM_APP_1.0</applicationId >
</Subscription>

Acme Packet Media (RTP) Troubleshooting

Who loves troubleshooting media issues? Not me. While some issues require a full packet capture, you can find out a number of things from a simple command. Like when you realize put a steering-pool in the wrong vlan…

I find myself using ‘show nat by-addr ‘ frequently. You do need to know the IP from the SDP c=line. A call must also be active when troubleshooting.

Basically this command gives you the VLAN info on the East / West sides from the call. It also provides the port used by the SDP (you can match this with your INVITE / 200OK ). It also displays the init_flow_guard, which in a normal scenario should be 4294967295.

The init_flow_guard is a timer that is set when the SBC receives a final 200OK of an INVITE transaction. If no media is sent, the timer begins to count down. As soon as the NAT table receives a single RTP packet, the ifg changes to 4294967295.

As always, mess around with it on your lab. See what you can discover on your network.
==========
sd1.# show nat by-addr 10.1.1.1

———————————
NAT table search address 801 :
Flow type: Fully qualified flow. Weight = 31
SA_flow_key : 10.1.1.1 SA_prefix : 32
DA_flow_key : 172.1.1.1 DA_prefix : 32
SP_flow_key : 0 SP_prefix : 0
DP_flow_key : 21136 DP_prefix : 15
VLAN_flow_key : 252
Protocol_flow_key : 17
Ingress_flow_key : 0
Ingress Slot : 0
Ingress Port : 0
NAT IP Flow Type : IPv4 to IPv4
XSA_data_entry : 72.X.X.X
XDA_data_entry : 216.X.X.X
XSP_data_entry : 24194
XDP_data_entry : 24120

Egress_data_entry : 1
Egress Slot : 1
Egress Port : 0
flow_action : 0X41
optional_data : 0
FPGA_handle : 0x00000000
assoc_FPGA_handle : 0x00000000
VLAN_data_entry : 193
host_table_index : 801
Switch ID : 0x00000002
average-rate : 0
weight : 0x1f
init_flow_guard : 4294967295
inact_flow_guard : 2
max_flow_guard : 86397
payload_type_2833 : 0
index_2833 : 0
pt_2833_egress : 0
qos_vq_enabled : 11
codec_type : 578155832
Call Recorder : 31304, Egress, Signal
HMU_handle : 578155832
sd1.ord1#