Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to learn more about Cisco Unified Boarder Element with Cisco expert Darryl Sladden. Darryl is in Cisco’s Access Routing Technology Group, where he is responsible for product management including driving features, market development, and positioning for the Cisco Unified Border Element. Darryl has been a product manager at Cisco in the area of VoIP, focusing on voice gateways and connecting across communications networks, for more than six years. He was previously the product manager of the highly successful Cisco AS5000 Voice Gateway product line. He has been at Cisco since 1998. Darryl holds a bachelor's degree in mathematics from the University of Waterloo in Canada.
Remember to use the rating system to let Darryl know if you have received an adequate response.
Darryl might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through January 29, 2010. Visit this forum often to view responses to your questions and the questions of other community members.
My question is about CUBE on the new 2900 and 3900 routers. Will the CUBE licenses still be trust based or will these routers keep track since now you have to activate this feature? If so, what would the show command be for the number of sessions installed and or inuse? How can I monitor the number of sessions used to stay in compliance? Also, why is the flat license not available in this new platform?
Great questions. The Border Element functionality on the 3900 and 2900 routers is still trust based. There is a new MIB that has the functionality with a single OID to keep track of the number of active sessions. That is one good way to keep track of the number of active sessions. Another method is to use the command "show call active | include legs". This will get you just the active number of call legs that is at the end of a "show call active command". This is the number of call legs. Each call has two legs are you are licensed for 2 legs for every call. (ie FL-CUBEE-5, means you are licensed to have up to 10 active call legs)
Finally, the flat license is not avialable for the new platforms because it was difficult for Cisco to help customer engineering their networks when we were not sure the number of sessions a platform could accomplish, when a "flat" license was purchased. It was like saying "I am not sure how fast this trunk can go with the cargo you are pulling, but however fast you can get to is the maxmium, your allowed to go" - Very confusing. Customers were able to better engineering their networks with the purchase and deployment of a fixed number of sessions on a platform which they can design the rest of their network around. This is especially helpful when running multiple applications and using a high end router such as the 3925 for example, for a small number of sessions, such as 25. In that case, a customer would only need to purchase an FL-CUBEE-25= license instead of a license for sessions that they may not use.
Does this help ?
Do you need to specific OID and MIB for the SNMP tracking or will you use the CLI command ?
Senior Product Manager Cisco Unified Border Element
That is good information. What about using it as H323 to SIP Gateway with media flow-through. Wouldn't that be 4 call legs for one call. In-out for H323 and in-out for SIP. How would that be counted? I have a 3845 running in this config. When I have about 150 simultaneous calls the numbers for call legs is about 600. The 3845 is suppose to only handle 500 CUBE sessions.
Follow-up: Ignore the above, I forgot MTP is also running on this router. That added two call legs to the total.
Thanks this is what I need to know
Good point on counting that MTP adds calls legs.
From a licensing point of view, you do not need to count the MTP calls legs in the licensed total.
Good Luck with your deployments,
Where do you can find information on the most usefull IOS Command set for Troubleshooting and Monitoring CUBE.
What is the basic set do you think everyone should use to this task?
Thanks In advanced for your answer
One of the benefits of the Cisco Unified Border Element is that it takes all of items command, architecture and debugging from Cisco Voice gateways.
Cisco Voice gateways have a many different debugging documents and I would recommend using searches of "voice gateway debugging site:cisco.com" as a way to find many links on debugging.
One good link that give general information is:
Other things that you may want to look are use of the "pipe" command to route CLI commands and help to focus in on what your looking for.
A good command is "show call active voice | include legs" only gives you call legs
or "show process cpu | exclude 0.00" gives you only processes that are consuming CPU.
As for SNMP, here are some important OIDs
Physical Chassis: Interface connectivity, CPU and memory
SIP: Monitor the issues/timeouts that occur with generic SIP signaling
Active calls: Monitor calls on a particular dial peer
Voice Quality Statistics: Active call stats, e.g. packet loss and round-trip time (RTT)
SIP Trunk utilization: Number of active calls based on protocol, dial-peer and interface, Call rate and spike
DSP utilization: report transcoding and MTP session information, configuration and statistics on used/available sessions
Hope this helps.
Senior Product Manager, Cisco Unified Border Element
Another helpful area for CUBE Troubleshooting is in the "Configuration Examples and Tech notes" page:
These App Notes mostly have a "Troubleshooting" section in with helpful cmds for the topic being discussed.
can we expect CUBE will be able to work as DBE in future, i.e. are there any plans/roadmaps to add H.248 in other devices apart from ASR1000?
The ASR1000 acts as a H.248 DBE today. Cisco is always looking at adding new functionality to ISR and other routers, but the right choice for H.248 DBE would be the ASR1000 in the short term.
Senior Product Manager, Cisco Unified Border Element
Cisco works with all SPs that offer SIP trunking with appropriate QoS/SLAs to enterprises and small businesses.
Specific SPs we have tested with and have configuration guides available for are posted at our interoperability portal:
www.cisco.com/go/interoperability > "Cisco Unified Border Element/SIP Trunking"
Are you able to compare a CUBE running on ISRs with a CUBE-SP running on ASR from features perspective and neglecting DBE functionality on ASR and performance which is obviously on ASR side?
The Cisco product portfolio contains two session border controllers, one in the Enterprise space (CUBE - Enterprise Edition) and one in the SP space (CUBE - SP Edition). Both products are supported on the ASR HW platform.
CUBE (Enterprise) on the ASR is the same code base as CUBE on the ISR (with higher capacity), and is optimized for connecting SP SIP trunks to CUCM and other IP-PBXs, as well as inter-enterprise H.323-SIP and SIP-SIP application interconnectivity. CUBE (SP) is a different code base and is optimized for the SP edge, SP peering and IMS applications.
My question is regarding early media in the 18X (SDP) sip messages.
When a call is placed from an IP phone on CUCM through CUBE into providers network via SIP callers are not hearing announcements, only constant ring back. I believe that these messages are sent as early media, is this true?, if so would changing the "SIPRel1XX Enable" parameter in CUCM (system>service parameters) from the default of diabled to enabled resolve this issue.
I beleive no changes would be necessary on teh CUBE as it supports PRAK by default.
You are correct in your analysis and conclusion. Enable PRACK on CUCM towards the CUBE, and make no changes on CUBE. This should resolve your issue.
Here's a quick question for SIP trunk redundancy with CUBE.
The goal of the config I'm looking for is to make the CUBE route to the next dialpeer when it receives a 403 response from the other end. I know that if CUBE receives a 503, 505 message or no response it will move on to the next dialpeer if "voice-class sip options-keepalive" is configured under the dialpeer. But is there something we can do for a 403 message?