Unanswered Question
Jul 11th, 2008

Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to get an update on how the Cisco Unified Border Element can provide secure and flexible VoIP network interconnecting services with Cisco experts Christina Hattingh and Darryl Sladden. 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 control, network services, and applications. 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. 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.

Remember to use the rating system to let Christina and Darryl know if you have received an adequate response.

Christina and 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 July 25, 2008. Visit this forum often to view responses to your questions and the questions of other community members.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
wowferhat Fri, 07/11/2008 - 13:54

Hi christiana,

I have a cisco router 2821 ready to be connected to a Siemens OTLE8 NT 4x2 Mbit/s Optical network termination Series in both end of point of a lease line, could you please which the right card should I use it

could you please explain the difference


VWIC2-2MFT-G703= Port 2nd Gen Multiflex Trunk Voice/WAN Int. Card - G.7032


HWIC-1CE1T1-PRI= port channelized T1/E1 and PRI HWIC

if you are not able to respond me please redirect me to anather expert.

Many thanks

hattingh Sat, 07/12/2008 - 09:04

This is not really the right forum for this question as this connection is unrelated to CUBE. I'm not familiar with the optical connections on a Siemens switch - is this a data or a voice connection? TDM or IP?

The VWIC2-2MFT-G703 will give you an unstructured E1, which is a pure data connection and cannot be used for voice. If this is a voice connection, then it has to be G.704 (structured E1), in which case you can use any of the VWICs and do not need the -G703 card.

The HWIC-1CE1T1-PRI card is also a TDM data connection for T1/E1 channelized data PRI. You cannot terminate voice using this card.

Neither of these card provide optical connections, they are all T1/E1 cards.



hattingh Tue, 07/15/2008 - 05:40

CUBE should always be used when a SIP trunk from a provider outside the enterprise network is brought into the enterprise. CUBE, as a session border controller, provides call admission control, session management and security services for terminating external traffic into the enterprise (in the DMZ typically) before it enters the protected part of the enterprise network. It also grooms traffic for the SP (QoS markings, call admission control, SIP trunk management) and offers a voice demarcation point for both the enterprise and SP to troubleshoot to.

It is not always necessary to use CUBE on a SIP trunk between two applications within the enterprise as security services are not typically necessary. However, quite often the interworking (H.323 to SIP) and SIP Normalization (SIP header manipulation) features are useful even in these situations.


akoukis Tue, 07/15/2008 - 05:10


It is true that a CUBE IOS does not support pstn cards like V2-2BRI-NT/TE when you using h323 protocol?



hattingh Tue, 07/15/2008 - 05:42

No, that is not true. Cisco IOS voice has always, since introduction in 1997, supported the H.323 protocol for PSTN cards (all of them).

You can integrate CUBE (IP-to-IP calls) and PSTN GW (TDM-to-IP) calls on the same Cisco IOS platform and use SIP and H.323 as needed for your deployment. For PSTN interfaces, MGCP is also supported.


akoukis Tue, 07/15/2008 - 14:23


I had successfully used MGCP with a CUBE IOS but when I try to use H323 to VIC2-2BRI-NT/TE I could n 't bring up the layer 2 of the isdn.

But thank you very much for your clear answer to my question



hattingh Thu, 07/17/2008 - 07:15

This sounds like a mis-configuration or a bug to me. Pls contact Cisco TAC for further help.

This feature is definitely supported, you can use a BRI voice card with any of the VoIP protocols (MGCP, H.323 and SIP) on the same platform. A port configured for MGCP cannot also handle calls with H.323/SIP at the same time (MGCP by its nature takes full control of a port and assumes exclusive control), but you could certainly have BRI port 1 being MGCP-controlled, and BRI port 2 being configured with dial-peers to switch its calls with either H.323 or SIP.



akoukis Fri, 07/18/2008 - 00:38

Hello Cristina,

you describe prefectly what I was tring to do.I have configure the first port of the VIC2-2BRI-NT/TE with MGCP protocol (control it by a CUCM 5.1.2)and it works find.The second port is configure with h323 and dial-peer but as I have told prevously when I place the bri line can not take up the layer2.I have test the config with simple voice gateway and it works fine and olso I have check the card to another router and it works fine.I will check for bugs but I not able to open TAC case because is an implemetetion that I did to my former company.I using the following ios c2800nm-ipvoice_ivs-mz.124-15.T5.bin with feature set INT VOICE/VIDEO, IPIP GW, TDMIP GW.



bbaley Tue, 07/15/2008 - 09:43

Can I upgrade my existing ISR to a CUBE?



hattingh Tue, 07/15/2008 - 10:29

Yes, absolutely you can. Depending on what IOS release you're on and which CUBE feature you'd like, you may need an IOS release upgrade. You also need to purchase a CUBE license (there are several options available).

More info in the CUBE ordering guide at:

You can also continue to run existing ISR data and/or voice services at the same time as using the ISR as a CUBE.



Naveen Raj Janardhan Tue, 07/15/2008 - 12:22

Hi Experts,

I keep getting this Alert from RTMT. what surprises me is that we are not using Attendant Console.

"Attendant Console Server heartbeat rate below 24 beats per minute. Current heartbeat rate is 14 beats per minute."

Can anyone please elaborate whats going on? Also, Do I need to restart any of the services? Thanks.

hattingh Tue, 07/15/2008 - 15:54

I'm sorry, I don't understand. How does this question relate to CUBE functionality?

Is this a CUCM related alert? It is coming from an IOS router?


mshadbol Tue, 07/15/2008 - 19:03

Can the CUBE support codec transcoding when used in a SIP-VxML context? Take this example to help understand my situation...

We communicate to our voicemail server via VXML. We SIP trunk from CUCM to the 3845, then invoke the VXML service against the matching dial-peer. The voicemail server can only record in G.711, but I need to be able to terminate calls received from WAN-connected locations, at G729.

So to work-around this codec mismatch, I want to accept an incoming G729 call leg, and transcode UP to G711, then match the outbound VXML leg. Is there any reason why this wouldn't be possible?

I'd expect that if trancoding is supported outside-the-box (ie, DSPs hosted on another router), I can't see why it couldn't also happen on the same router.

I understand there is a limitation in dynamically negotiating codecs on IP-to-IP call legs, but it would be acceptable for me if we could hard-code the inbound leg to G729 and the outbound VXML leg to G711.

(I have a TAC case open on this, but they don't seem real sure of what is/isn't feasible).

Finally, if this is possible, are there platform limitations? We are trying to prove the concept on ISR hardware, but a production environment would preferably be executed with AS5400XM hardware. And what IOS versions are required.

If this isn't possible, what would be your suggestion for handling such a situation?

Look forward to your reply.



steven_chan Wed, 07/16/2008 - 06:56

Hi, take as an example. For H323 to SIP, using 108 as incoming and 103 as outgoing dialpeer.

Should the configuration be like this?

dial-peer voice 108 voip

incoming called-number 40..

dtmf-relay h245-alphanumeric

codec g711ulaw

(keeping dialpeer 103 unchanged)

What is the usage of

dtmf-relay rtp-nte digit-drop h245-alphanumeric

in dialpeer 103?

From the configurtion guide,

"Configure the dtmf-relay rtp-nte digit-drop command on the incoming SIP dial-peer."

"The following example shows DTMF-Relay digits configured to avoid sending both in-band and out-of-band tones to the outgoing leg in an Cisco Unified Border Element:

dial-peer voice 1 voip

voice-class codec 2

dtmf-relay rtp-nte digit-drop h245-alphanumeric"

I am confused. Please explain. Thanks in advance.

hattingh Thu, 07/17/2008 - 07:06

Not sure I follow the references to dial-peers 108 and 103. In the example you give the URL to, there is an incoming dial-peer 200 and an outgoing dial-peer 100, both SIP. If you want to make that config to become H.323 to SIP, just drop the "session protocol sipv2" from the dial-peer.

If you want H.245-alpha DTMF relay on the H.323 leg, then put "dtmf-relay h245-alphanumeric" on the H.323 dial-peer.

In this specific example you will only have H.323 calls coming *in* and SIP calls going *out*, so the "digit-drop" thing is not applicable.

If you structure the dial-peers to be in both directions, and had a call flow from SIP (RFC2833) to H.323 (H.245-alpha), then you would need the digit-drop CLI on the H.323 outgoing dial-peer. What this means is that on the incoming leg you have inband DTMF (RFC2833, or rtp-nte). This is translated to an out-of-band (H.245-alpha) method, so you end up with DTMF both inband and out-of-band on the outgoing leg which gives duplicate digits and some applications don't like that. To force CUBE to delete the inband DTMF and send only the out-of-band method on the H.323 outgoing leg, use the "digit-drop" CLI.



hattingh Thu, 07/17/2008 - 06:54

Yes, this should be possible, G.729 dial-peer on one side and G.711 on the other with the VXML app attached. If it doesn't work straight through, we may have to experiment with multiple dial-peers to get it to work.

Yes, you can do xcoding with either onbox or offbox DSPs. More info on this at

And yes, if it works on an ISR, the same call flow should also work on a 5400XM. Xcoding on the 5400XM is only supported on the newer DSP cards (the AS5X-PVDM2-64 DSP card). For IOS you'd probably be best off using the latest, which is 12.4.20T. Failing that 12.4.15XZ or 12.4.15XY.

Couple of other things, there is currently one DDTS open that might affect this call flow: CSCsq03028: SIP-H323 - IVR failing to invoke Transcoder and send DTMF correctly.

Also, for this call flow, you will require both CUBE and VXML licenses on the box (FL-VXML and FL-CUBE).



ryan_oconnell Wed, 07/16/2008 - 11:44

I was considering using CUBE as a translation device between H.323 with Gatekeeper and Mitel 3300. The idea being have Mitel SIP trunk into CUBE and have CUBE register to the same gatekeeper that is used to tie two CallManager clusters together. Is this possible? Also if it is possible could CUBE also pass through Gatekeeper requests. Example if Mitel makes a call that is routed via Mitel --sip-->CUBE--h323-->gatekeeper and gatekeeper returns ARJ. Would the rejection be send back just too CUBE or would the SIP trunk back into Mitel be aware there is no route in place so alternative routing via PSTN could take place.

hattingh Thu, 07/17/2008 - 07:10

Yes, this is possible. You can either use an external GK, or you could use the GK code integrated on the same platform as CUBE.

CUBE does not "pass through" GK requests to the Mitel because GK msgs like ARJ have meaning only on H.323 and has no meaning on SIP. But the e2e call flow will work. The SIP call from the Mitel arrives at CUBE, CUBE sets up a req to the GK, the GK denies it (ARJ), and CUBE denies/fails the SIP call back to Mitel. The Mitel can then use its alternate routing logic to try another path.



tenaro.gusatu.novici Wed, 07/16/2008 - 23:56

Hi Christina,

could you plese describe the differences between SBC and CUBE. Please take into account that I'm technical person and as such I'll appreciate if you can focus on features&functions rather than price&performance.



hattingh Thu, 07/17/2008 - 07:42

They are both session border controllers so in that sense they have largely similar features/functions. The primary difference is that of scale and place-in-the-network, CUBE is an enterprise interconnect (either applications within the enterprise, or enterprise-SP) product while the 7600/12K Cisco SBC is primarily a SP-peering product. For that reason CUBE has more enterprise-specific features and the SBC has more IMS-related features.

Architecturally they are also very different. The SBC is a decomposed product with a data portion (DBE) and a signaling portion (SBE) that communicate via H.248. The DBE and SBE can run on different platforms. CUBE is an integrated IOS feature, does not require any blades, and does not support H.248 or the separation of signaling and media control.

CUBE can do on-platform xcoding (using ISR/5400 DSPs), the SBC can not. There is an external xcoding solution for the SBC using an MGX platform with DSP capability.

CUBE has rich enterprise interconnect features, such as RADIUS-based accounting, digit manipulation/translation features, per call translation/manipulation of SIP headers, more flexible codec and xcoding support, SIP DE-EO interworking, a rich set of DTMF interworking options (22 combinations), TLS support, simpler configuration and debugging, SNMP MIB support, H.323 video support etc.

Also, because CUBE is an integrated IOS feature, it can be collocated on the same platform as various other IOS features providing unique solutions, such as TDM GW (easy SIP trunk to PSTN failover or easy migration from one to the other), VXML control (ContactCenter/CVP integration of SIP trunks), SRST, FW, integrated H.323 GK etc.

But for basic IP-to-IP calls and general session border controller features, both product categories can do that.



tenaro.gusatu.novici Fri, 07/18/2008 - 00:47

Wow, this is great answer!

Before we conclude this, could you please confirm following statements so I'm sure I understood everything you said:

- when SBC (7600/12k) is used in standalone mode, i.e. when working as DBE+SBE is it still using H.248?

- SBC (7600/12k) can work as DBE only or SBE+DBE but in either case can't do transcoding itself, i.e. it must use external DSP resources from MGX; right?

- is MGX only SBC in Cisco portfolio with integrated DSPs when working in DBE mode?

- can we use ASR as DBE and do we still need external DSPs to control media?



dsladden Fri, 07/18/2008 - 14:19


- When the 7600/12k is used in standalone mode, there is an internal protocol, that is effectively H.248 that is used between the DBE and SBE components that are running on the same platform.

- Correct, 7600/12K cannot do transcoding without the resources from an external DSP on the MGX.

- MGX cannot function as a SBC without a controlling entity. The only SBC at Cisco that supports both SBE+DBE+Transcoding in the same box is CUBE on the ISR or AS5X.

- When you use ASR as a DBE, today you need external DSP to transcode media. DSP are not needed to transport media if both side of the call use the same codec.

Hope this answers your questions.


Darryl Sladden

Cisco Unified Border Element

Senior Product Manager

tenaro.gusatu.novici Thu, 07/24/2008 - 03:28

Thanks Darryl,

if ISR and AS5XXX are supporting CUBE functionality then they don't support H.248 and can't be controlled by PGW, right? In addition, if I want to use ASR as SBC in DBE mode (controlled by H.248) to control media streams (change codecs, for example), then I acctually need ASR + MGX + PGW, correct?



hattingh Thu, 07/24/2008 - 08:02

Correct, CUBE (5x00, ISR) cannot be controlled via H.248from PGW or anywhere else. You can direct SIP or H.323 call flows from the PGW to CUBE.

You are correct on your 2nd question also.


Sushil Kumar Katre Fri, 07/18/2008 - 02:15


In case I want to terminate an IP PSTN connectivity and the provider is providing SIP trunk, does CUBE becomes mandatory in UCM setup?

-> Sushil

dsladden Fri, 07/18/2008 - 14:22


CUBE should always be used when a SIP trunk from a provider outside the enterprise network is brought into the enterprise. CUBE, as a session border controller, provides call admission control, session management and security services for terminating external traffic into the enterprise (in the DMZ typically) before it enters the protected part of the enterprise network. It also grooms traffic for the SP (QoS markings, call admission control, SIP trunk management) and offers a voice demarcation point for both the enterprise and SP to troubleshoot to.

Because of all of these reasons, the recommended solution is to have CUBE in the UCM setup.

shajimoorkoth Sat, 07/19/2008 - 12:19


Could you please brief me about License requirement for CCMe and IP Phones.

Following Licenses are same ? Do i need to Oder Both?



hattingh Sat, 07/19/2008 - 16:08

No, they are not the same. CME and CUCM both require both software/seat license (which means the call agent software for the user), and a phone license (for the physical phone).

FL-CCME-xxx are the seat licenses. SW-CCME-UL-xxx are the phone licenses.

The newer bundled options, FL-CCME-UC-xxx, include both the seat and the phone license in a single SKU. So FL-CCME-UC-25 gives you CME seat and phone licenses for 25 users. SW-CCME-UL-7945 gives you a phone license for one 7945 phone user.

This might help:



shajimoorkoth Sat, 07/19/2008 - 20:50


Thank you very much for you r support.

I am clear about Licensing part.

Hello Cristina,

I have two gatekeepers (GK1, GK2 - Cisco ISR 2821 with ios c2800nm-ipvoice_ivs-mz.124-17a.bin.). Configurations:



zone local GK1 192.168.x.x

zone remote GK2 192.168.x.y 1719

zone prefix GK2 111....

no shutdown



zone local GK2 192.168.x.y

zone remote GK1 192.168.x.x 1719

zone prefix GK1 222....

no shutdown

h.323 terminal T1 registered to GK1 with number 1001 and h.323 terminal T2 registered to GK2 with number 2002.

I have a problem with Inter-zone calls. For example, T1 place a call to T2 by dail number 1112002. Remote gatekeeper GK2 send to its neighbor GK1 RAS message LRJ with reject reason - undefined reason.

What is the cause of this problem?

if you are not able to respond me please redirect me to another expert.

Many thanks

hattingh Mon, 07/21/2008 - 08:12

Not sure. Your setup and dial plan look correct. The general reasons why a GK would reject a call is due to bandwidth restrictions, endpoint registration and dialed number. Not sure if tech-prefixes, or some default tech prefixing is perhaps involved? Maybe take a look at the CLI "gw-type-prefix 1#* default-technology".

Here are some links that might help. If not you may have to contact Cisco TAC to help you troubleshoot. I can't think of a reason why this application should not work.





matthewpage Mon, 07/21/2008 - 12:17


I have been having a bit of a nightmare getting this going but basically the call flow is as follows:

PHONE -- G729 -- CCM -- H323 G729 -- IPIPGW --G729 SIP -- Verizon

what would i need for this call leg? a MTP or a transcoder? and why?



matthewpage Mon, 07/21/2008 - 13:01

That looks great. Added to this i have calls going to unity and ARC which is g711. So call would probably look like this;

Verizon - G729 sip - IPIPGW - G711 CCM - G711 - UNITY

So on top of the MTP i would also require a transcoder??

Currently i am using both MTP and Transcoder but every second calls seem to fail.

Thanks for you help


csg-admin Tue, 07/22/2008 - 07:31

I have this setup on 12.4(15)XZ


CUCMB is acting as a SIP SP.

I can make G729 and G711 calls from CUCMA and accept G729 and G711 calls from CUCMB - no problems.

However, if I receive a G711 call from CUCMB and then transfer this to a G729 phone on CUCMA the call goes dead.

I've configured on board transcoder on the CUBE and all devices and trunks are in device pools with MRG's with transcoders. I cannot get this to work.

Is this a limitation of the CUBE????


hattingh Wed, 07/23/2008 - 06:39

It may be a limitation of the entire solution. I'm not sure this will work even if you take CUBE out of the picture. The issue surrounds mid-call insertion of a xcoder, which isn't supported on CUBE and not sure of CUCM.

CUBE xcoding is triggered purely by a codec mismatch between the two VoIP dial-peers (an MRG configuration is irrelevant to CUBE xcoding - that is the way to configure CUCM xcoding) on the initial call setup, but it isn't triggered on mid-call modification.

CUCM xcoding (this is where MRGs and device pools are used) may or may not solve the problem. Do you have a DSP pool somewhere that CUCM controls so that it has access to switch in a xcoder? It cannot be the same DSPs that are configured as CUBE xcoding resources.

Overall it would be better to configure the phone to support both G.729 and G.711.



csg-admin Wed, 07/23/2008 - 07:54

Thats a problem then if you centralise your SIP presentation at your head office. Calls here would be G711 and it would mean that you could never transfer calls across the WAN to remote sites using G729 :(

hattingh Thu, 07/24/2008 - 07:08

Well, there's usually a way to make these things work, but it requires detailed analysis of call flows and configuration tuning. A CUCM expert I queried about this suggested that the following may be happening: "CUCMA is not inserting the xcoder in this call flow but is asking both sides to move to G.729. I think what is happening is that the CUCMA sends a re-invite back to the CUBE over the trunk asking to move the codec to G.729 which it doesn't do and hence the call fails."

He suspects further that: "The originating endpoint is probably saying that it can support both G.711 and G.729 in the initial INVITE so the CUCM thinks it can change the media mid-call. Ask them if they can restrict the codec list in the initial offer to only G.711. In that case, the CUCM will be forced to allocate a transcoder."



hattingh Wed, 07/23/2008 - 06:48

MTPs are required by CUCM and whether or not you need one depends on the CUCM configuration and release levels. CUBE never needs MTPs or has any dependency on an MTP. Although the same IOS box that is used as CUBE can also be the MTP host for CUCM.

For the call flow you give you will need a xcoder on CUBE. This is configured on CUBE itself and uses DSPs under CUBE control to xcode the call, triggered by a codec mismatch on the dial-peers during the initial call setup. More info on configuration at:

Is the CUBE-CUCM connection H.323 or SIP? What release level of CUCM and Unity? I can try to find info on when/whether CUCM requires an MTP for this call flow.



ErBurger1 Wed, 07/23/2008 - 20:09


I have the following topology:

Verizon -- SIP --- IPIPGW -- H323 -- UCM

UCM version 6.1.1

3825 running 12.4.15T6

I am having issues trying to use g729 for voice and g711 for fax.

I have been using the following guide:

Verizon requires Early Offer. In the dial-peer examples I see the codec is set to transparent. When I do this the calls always seems to use whatever codec I have set under the "codec for outbound faststart" in the gateway configuration.

I also needed to add an MTP and CFB on the router when I was running g729.

What would be the recommended configuration of UCM and the router for this? Should I send everything to the router as g711 and transcode only the voice calls to g729 on the router?



hattingh Fri, 07/25/2008 - 12:07

I think you should be able to do G.729 for normal voice calls and use T.38/passthrough (G.711) for fax w/o xcoding everything. The example doc that you cite actually uses G.711 on all the dial-peers and not codec transparent. Codec transparent is currently supported only for H.323 so that is not the right configuration for a SIP trunk.

The AT&T Application Note posted at may be of more help. I know you're connecting to Vz, but the requirements are the same, G.729 for normal voice and T.38/G.711-passthrough for fax and the AT&T covers CUBE and CUCM configuration for that call flow. Specifically, the "fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback" cmd under voice services voip may help.



bensanden Thu, 07/24/2008 - 11:25


We are about to integrate 8 separate CUCM 6.1 clusters with gatekeeper-controlled intercluster trunks. The SRND Best Practices state that we should use via-zone gatekeepers w/ CUBEs in this scenario. It looks like the advantage of integrating CUBEs in our environment would be the ability to utilize RSVP between clusters. Our concern is that this would require Media Flow-Through, and forcing all inter-cluster RTP traffic through the CUBEs might result in sub-optimal routing and put a high load on the CUBE router. All 8 CUCM clusters are connected via high-speed Packet over Sonet with less than 11ms one-way delay from the two furthest clusters on the network. All sites are also in the same OSPF AS, so there is no need for IP Address hiding. If we can get by without using RSVP for inter-cluster calls, and there is no need for IP address hiding, are there any other features or advantages that a CUBE would bring to the table when compared to a plain old gatekeeper-controlled ICT architecture?

Thanks for your insight.

dsladden Thu, 07/24/2008 - 12:50

As you describe the senario, the most widely deployed solution would be to use gatekeeper-controlled ICT architecture. Since you are not using RSVP, have no need for IP address hiding or additional security layers between the different clusters, your idea of using standard ICT architecture makes sense. This may be an architecture you re-examine every couple of years to ensure that it still addresses your needs. (ie Start using RSVP in future.)

tenaro.gusatu.novici Thu, 07/24/2008 - 12:37

Last one from me :)

I would like confirmation if CUBE can be used in following scenario: I have music server on one side of the network (or any IP audio streaming server, if you want that way) and many IP phones on another side of the network; can I put CUBE in between so it can accept unicast audio stream, maybe change the codec and forward this as multicast to IP phones? Acctually, signaling will be opposite: first IP phone will send join to the CUBE and then CUBE will ask music server to send a unicast stream which will be converted to multicast so many devices can listen this music.




This Discussion