Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to get an update with Cisco experts Christina Hattingh and Darryl Sladden on how to integrate SIP trunks for PSTN access from Service Providers with IP Telephony environments. Darryl Sladden 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. Sladden 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. Christina Hattingh is a technical marketing engineer in the branch office Unified Communications group at Cisco, focusing on unified communications technologies and network deployments on the Cisco 2800 and 3800 Series Integrated Services Routers. Unified communications technologies integrated in Cisco IOS Software offer numerous communications services, such as voice and video gateways, call contro, network services, and applications.
Remember to use the rating system to let Christina and Darryl know if you have received an adequate response.
They 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 August 10, 2007. Visit this forum often to view responses to your questions and the questions of other community members.
I have implemented a CUBE (when it was the Cisco IPIPGW :-) for video conferencing. However, I'm unclear on how to configure transcoding resources (DSPs) directly on the CUBE rather than DSP resources that are registered with CUCM.
In this scenario, are DSP resources configured in a similar manner to CUME, e.g.
ip source-address 192.168.1.1 port 2000
sdspfarm units 1
sdspfarm transcode sessions 16
sdspfarm tag 1 MTP000f23cd6100
sccp local Vlan10
sccp ccm 192.168.1.1 identifier 1
sccp ccm group 1
associate ccm 1 priority 1
Or, are the DSP resources simply just available to CUBE for trancoding and don't require any explicit configuration?
You have the correct configuration above. DSP resources for xcoding must be configured at all times (it doesn't work without that). The configuration is largely the same for CUBE and CUCM. In CUCM's case the "sccp ccm 192.168.1.1 identifier 1" points to the IP address of the CUCM, in the case of CUBE the same CLI matches the IP address in the "telephony-service, ip source-address 192.168.1.1 port 2000" CLI. That's really the only diff in the configs.
Some other points:
- Xcoding cannot be done for video traffic, it's only applicable to voice traffic.
- The DSP resources used by CUBE do not have to be resident on the same box as CUBE. Usually it is (and your RTP stream flows through whatever box has the DSPs in), but it does not *have* to be on the same box.
- Xcoding is only invoked by CUBE if both of the following are true for a voice call, (i) DSP resources for xcoding is configured, and (ii) there is a non-negotiable codec mismatch between the two call legs of the call.
Many thanks for your informative response. The point about using non-local CUBE DSP resources is useful; I'm looking at an implementation of CUBE for Voice hence the query regarding voice transcoding.
The Networkers' slides touch on using DSP resources with CUBE, but the documentation doesn't really expand on it.
You're right, the documentation links leave some to be desired. One place to look is the docs on any-to-any codec transcoding introduced in 12.4.11XW for CUBE. This doc is linked from the 12.4.11XW release notes:
I am not clear as to where in my Cisco Unified Communications Manager (CUCM) network I should deploy a Cisco Unified Border Element?
As CUBE can perform many different functions, there are various reasons to deploy a CUBE, and various places in the network where it may fit. Only a subset of these may apply to your particular network situation. Some of the common ones include:
- H.323 to SIP interop: If you have an older CUCM cluster capable only of H.323 and wish to deploy/upgrade another CUCM cluster to a newer release that is SIP-capable, you can bridge these two realms by putting a CUBE in the middle to provide H.323-SIP interop until such time as you upgrade all CUCMs to SIP.
- H.323 to SIP interop: Following on from above, you could connect an H.323 CUCM cluster to any newer SIP gear in your network if you wish to start deploying SIP proxies, MCUs, apps... but do not wish yet to upgrade your CUCM. One place where where this is used is with MeetingPlace using SIP.
- IP address hiding: If you have a merger/acquisition in your enterprise and have to integrate voice equipment (CUCMs, IP PBXs VM servers, etc.) that have overlapping IP addresses with the rest of your network, you could use a CUBE to connect the two distinct networks until such time as they can be migrated into your enterprise addressing plan.
- IP address hiding: Following from the above situation, if there are any security concerns between your network and the "acquired" network, a CUBE (being a B2BUA) can provide a demarc between the two networks to mask one from the other until the security issues are worked out and you no longer need a demarc.
- SIP Trunk termination: If you bring a SIP trunk from a SP into your enterprise, it's best to terminate this onto a CUBE and not directly onto CUCM. This practise provides security, topology hiding, transcoding, call admission control, protocol normalization, SIP registration, and various other network demarc capabilities that you would lose if you connect directly to CUCM (and which you had with TDM GWs to the PSTN).
- ICT CAC: If you need RSVP CAC on your H.323 ICTs between CUCM clusters, CUBE can provide this function.
Am I correct in understanding that H.323 can only bind to one IP address on the CUBE ('h323-gateway voip bind srcaddr' under interface configuration)? If I wish to use the CUBE to terminate and regenerate H.323 call legs for address hiding, is the only mechanism to change the source address used for the outbound leg to use IOS NAT on the CUBE itself (assuming it's fully H.323v4 aware) or to use another H.323 aware device to perform NAT and firewalling such as an ASA?
Yes, you are right there is a single global "bind" address per CUBE. There is one for H.323 and a separate one for SIP, so if you do H.323 to SIP you can bind to 2 different addresses, but if you do H.323-H.323 or SIP-SIP, then you only have one.
If you do not use the bind cmd at all, but have two physically different interfaces going to the two sides (typically "inside" and "outside"), then the packets will pick up the source address of the physical egress interface, which may serve your needs. If you have a single physical egress interface for both inside and outside, then of course this does not help.
You could use 2 separate CUBEs in your DMZ, one for outside-to-DMZ, the other inside-to-DMZ, in which case you can bind each CUBE to the appropriate address.
CUBE provides a true L7 NAT as it is a B2BUA and therefore fully terminates and re-originates every packet. External NAT devices tend to leave some deep packet embedded IP addresses exposed.
Where can I find good example on how to integrate SIP between
1- CallManager and Astrisk using SIP
2- IOS voice router and Astrisk using.
Third party interoperability is achieved by Cisco's extensive participation in independent testing events, and conformance with H.323 and SIP standards. For a complete list of SIP RFC compliance of Cisco IOS, refer to the ?Achieving SIP RFC Compliance? document at http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_configuration_guide_chapter09186a00807561f1.html.
I have no specific information on Asterisk integration.
Hi. I?m studing CCDA because I have to do the exame in this year! I want ask what are the news in the NEW CCDA Version?
Do you indicate how I study for this?
Thanks a lot.
I'm afraid you may want to try another forum for this question. The topic here is Cisco Unified Border Element (CUBE) and I haven't knowledge whatsoever of CCDA curricula.
Should I use IOS NAT, a NAT appliance, or a Cisco Unified Border Element to hide the IP addresses of my enterprise IP phones behind a SIP trunk?
You can use any one of these, with increasing level of protection:
- A basic NAT appliance: L3 address substitution only (many SIP IP addresses are embedded deeper in the pkt and a NAT appliance do not translate these)
- SIP NAT ALG: L4-L7 IP address substitution, but there are still some addresses used in some SIP headers which are not translated by these ALGs, so there is still IP address leaking exposure depending on the specific call flow used and the specific ALG used
- CUBE: Complete L7 IP address conversion. CUBE is not a NAT device, it is a B2BUA, which means it terminates the SIP streams and reoriginates them from its own IP address. This offers full "deep pkt inspection" as the SIP packets are not passed through (what NAt devices do), they are originated from CUBE.
My recommendation is that you should use a CUBE for SIP trunk termination into an enterprise.
Hello, have a question. Table 4 on page 29 of the "ipipgw ccmigration_09186a00803ff3f3" document (http://www.cisco.com/application/pdf/en/us/guest/products/ps5640/c2001/ccmigration_09186a00803ff3f3.pdf) shows that most of the supplementary services just don?t work on an interworking scenarios h.323 to sip. The question is how should I interpret this information since I have all of them enable and working without problem in an h.323 to sip scenario with a CCM 4.1(3) and a 2801 IPIPGW?
Glad to hear it's working for you. You don't mention what release you're running. The doc is applicable to 12.4.11XJ. A list of additional supplementary services are possible as of 12.4.11XW with the support of H323 ECS <-> SIP (re)INVITE. The doc seems not to have been updated yet for this content.
I had deployed IPIP GW for SIP trunks and interworking with H.323 without any problema. I want to ask you what are the most significant new features we could find in the CUBE that would'n find on the IPIP GW.
For what type of implementation we can use it?
Or the reason to change the name from IPIP GW to CUBE is only a marketing campaing?
Thanks in advance.
ou can send data (other than you or video) through CUBE, if so, it is necessary that you implement codecs such as G.711 or other? That is my question
I don't know what you mean by "raw data", but in general CUBE does not use DSPs for any sessions unless they need transcoding or transrating.
However, codecs will be negotiated for all calls (without DSPs) end-to-end, so setting up a CUBE session other than audio or video is not possible.
With raw data I mean the general data network, ie traffic that is not video or audio (or transfer such a folder, things like pinging), which wanted to know is whether to spend this kind of traffic is must encode it using a codec and DSP use, not if you can help me answer this question
General network traffic will be handled by the router itself (pings, data traffic...), so yes, you can pass any traffic you like through the router where CUBE is running. But CUBE, as a session border controller feature set, handles only SIP and H.323 sessions, so this other traffic will be transparent to CUBE.
The specification of a codec for session negotiation is required. There is a lengthy list of supported audio and video codecs.
CUBE and IPIPGW is the same product (and therefore have the same features), it was merely a name change to bring the IPIPGW (older name) into the Cisco Unified portfolio of unified communications products.
CUBE is used as an enterprise session border controller in 4 primary deployments:
- SP SIP trunk interconnect to enterprise PBXs (SIP and H.323)
- Inter-enterprise application (SIP and H.323) interconnect
- Telepresence business-to-business interconnect (SIP)
- H.323 internet video interconnect
Additionally CUBE is used to solve a variety of other enterprise problems such as:
- to provide a security demarcation between different departments (e.g. government institutions or school districts)
- to provide call admission control between different segments of a network
- to provide topology hiding (IP address translation) when integrating a merged/acquired company's network
- to provide transcoding and transrating interconnect services