cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11797
Views
20
Helpful
37
Replies

Ask the Expert: Cisco Unified Border Element (UBE) Enterprise

ciscomoderator
Community Manager
Community Manager

With Robin Cai

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to and ask questions about how to design and troubleshoot Cisco Unified Border Element  (UBE)  for the enterprise with Cisco expert Robin Cai.  You can ask questions on how UBE works in different call scenarios, including normal calls, hold/resume, call transfer, call forwarding, as well as best practices.

Robin Cai is a senior customer support engineer in the Cisco Technical Assistance Center in Sydney. His current role includes configuring, troubleshooting and designing Cisco Unified Border Element Enterprise and Service Provider,  voice gateways, and Cisco Unified Communications Manager. He has  in-depth knowledge of Cisco and industry signaling protocols. He has more than 11 years of experience working in the telecommunication industry. Previously at Cisco he was a senior software test engineer at the China Research & Development Centre in Shanghai. Before joining Cisco, he worked for UTStarcom as a field support engineer and for Huawei Technologies as a software development engineer. Cai holds a bachelor's degree in computer science from Nanjing University of Science & Technology. He also holds CCIE certification (#26037) in Voice and Routing & Switching.

Remember to use the rating system to let Robin know if you have received an adequate response to your technical support question. 

Robin might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the  Collaboration, Voice and Video sub-community discussion forum shortly after the event.   This event lasts through December 21, 2012. Visit this support forum often to view responses to your questions and the questions of other Cisco Support Community members.

1 Accepted Solution

Accepted Solutions

James Hawkins
Level 8
Level 8

Hi Robin,

I am hoping that you can help me with some security questions for SIP trunks. I have configured CUBE on a 2900 ISR to link to an Internet Telephony Service Provider and want to make sure that it is secure.

I have connected Gi0/0 to an inside VLAN and Gi0/1 to the public Internet with a registered address.

So far for security I have set the ip trusted address list feature to include just the CUCM server and the IP address of the SIP provider

voice service voip

ip address trusted list

  ipv4 10.1.1.11 255.255.255.255              <-------------- CUCM server 1

  ipv4 222.222.222.222 255.255.255.255     <-------------- ITSP SIP server

address-hiding

mode border-element

I also have set an ACL to limit inbound connections from the Internet to SIP signalling and media traffic from the ITSP server

interface GigabitEthernet0/0

description CUBE Inside Interface

ip address 10.3.1.4.11 255.255.255.0

duplex auto

speed auto

!

interface GigabitEthernet0/1

description CUBE Outside Interface

ip address 111.111.111.111 255.255.255.255

ip access-group SIP-Inbound in

no ip unreachables

no ip proxy-arp

!

ip access-list extended SIP-Inbound

permit udp host 222.222.222.222 host 111.111.111.111 eq 5060

permit udp host 222.222.222.222  host 111.111.111.111  range 6000 40000

deny   ip any any log

!

I also set the call spike feature

!

call spike 5

!

I also limit the number of connections on the SIP ITSP dial peer

dial-peer voice 100 voip

description Outbound SIP calls

max-conn 40

destination-pattern .T

session protocol sipv2

session target ipv4:222.222.222

voice-class codec 1

voice-class sip privacy-policy passthru

voice-class sip early-offer forced

!

Note that the ITSP does not offer SIP registration by username/password or any form of encryption.

Is the above configuration secure or do I need to deploy a firewall in front of the CUBE?

If I should use a firewall this could be challenging as the customer uses Watchguard firewalls and I would have to move the outside interface of the CUBE to the WatchGuard DMZ. Hosts in the DMZ use private addresses so the Watchguard would be doing NAT which I guess could be tricky.

Are there any other forewall options you would recommend? e.g.

  • IOS Firewall - could I just enable this on the CUBE and get it to do SIP inspection? - I have been trying to find a sample config for this without success.
  • ASA Transparent firewall - deploy one of these as a bump in the wire between the CUBE and the ISP router.

Is there any value in configuring stateful inspection on firewalls for SIP or does this just replicate what the CUBE itself does?

I am also interested in other security features that could be enabled. What would you recommend I configure?

Thanks

James

View solution in original post

37 Replies 37

Marcelo Vieira
Level 1
Level 1

Hello Robin,

I am migrating our voice network from PRI circuit to SIP trunk via CUBE. There are one internal address and one public address (assigned by Telco). Is it necessary to configure NAT for internal and external signalling and media communication?

Thank you for your prompt response.

- Marcelo

Hello Marcelo,

Thanks for your question.

It's recommended not to configure NAT on CUBE if there is no specific reason. Useally as long as CUBE can reach internal and external network, it chooses the best local address and communicate with internal device (e.g. CUCM) and external device (e.g. Telco's SBC) properly.

In some cases, you may need to specific the source ip address of signalling and media on CUBE, which can be archieved by using "SIP bind features". It can be configured globally or under dial-peer as below:

voice service voip

   bind {control | media | all} source-interface ...

or

dial-peer voice tag voip

   session protocol sipv2

   voice-class sip bind {control | media} source interface ...

Also CUBE provides many security features (including but not limited to topology hiding, SIP protocol inspection, toll-fraud protection) for the unified communication sesssions that pass through it.

Please let me know if you have any questions.

Thanks and regards,

Robin

Steven Griffin
Level 4
Level 4

Robin,

When using CUBE in media flow-around mode what call admission control options do we have that can track both SIP calls and inter-office on-net calls to/from satellite sites on the same MPLS network?

This situation occurs when you leverage your MPLS provider as your SIP provider.  Now you can source your calls from the provider's network and direct them to your satellite offices directly rather than loop the RTP through your datacenter or HQ site.  Thus, ostensibly, the signaling still goes through your CUBE router but RTP is direct from provider to the phone at the satellite office.

While this is great and saves bandwidth, I've struggled to find an acceptable CAC mechanism that can track bandwidth used both for on-net and SIP provider calls.  Locations CAC is problematic and limiting. RSVP Call Agent isn't supported in media flow-around mode.  The answer might be CUCM SME but truth be told, I'd rather not install a CUCM SME for just CAC.  For many installations it is too expensive. 

- Steven

Please help us make the communities better. Rate helpful posts!

Hi Steven,

Thanks for your question.

As per your description, if I understand correctly, the network topology is as bleow:

CUCM@HQ ---(SIP)----CUBE------(MPLS)----(SIP)----....------TELCO

                                                                      |

                                                                      |--(SIP)---Satellite BR

So the issue here is it's difficult to find an acceptable CAC track on-net and SIP provider calls, please correct me if it's not accurate.

In this case you can use the "max-conn" to limit the max calls being sent to Telco or Satellite Branch office under different dial-peer on CUBE.

Another way may help, which is to use seperate sip trunks with different device pool/location on CUCM. To achieve this, on CUBE add a loopback interface and assign it with another internal address; From CUCM side, there will be two sip trunks pointing to two different addresses of CUBE for different uses (one for on-net call, the other for sip provider). Thus CAC policy can be applied on the sip trunk seperately.

Note, when the call is being routed out CUBE, you need to specify the source address of signaling under dial-peer level.

Hope this helps. Please let me know if you have any questions.

Thanks and regards,

Robin

Robin,

You describe the situation mostly correctly but fail to understand the need. The one item of correction to your diagram is that all the satellite sites are centrally managed by the CUCM cluster.  Thus, I need a way to apply CAC consistently at each satellite site using that site's bandwidth.  Calls can be from the SIP Provider (managed centerally by the CUBE router & CUCM) or they can be on-net calls from the HQ, another satellite location, or another CUCM cluster.  On net calls consist of MeetingPlace, UCCX, Voicemail, or just plain audio/video calls between 8945 model phones.

Since the dialing plan is centralized on CUCM the max-conn command isn't really going to work.  It also doesn't solve the problem of understanding and applying CAC consistently at each site regardles of the call origination point. Right now the only option I have is to carve out bandwidth in QoS just for SIP calls and reduce the amount of bandwidth available for other on-net calls using the normal CAC mechanisms (Locations/RSVP) and then hope the SIP calls don't exceed or overlap with the on-net calls.  This is less than ideal.

The other option you discussed is terminating a SIP signalling session at each site. While this might work it adds undue complexity, cost, and doesn't scale well.  No one wants to maintain copies of the enterprise dialplan at each router, SIP trunks and CUBE licenses are not cheap, and this quickly becomes unmanageable.

I can obtain a consistent CAC experience if I use media flow-through mode but then I have to double up the bandwidth at the HQ site on the CUBE router and hairpin satellite office calls back through the MPLS network to the satellite site.  This doesn't scale.  The bandwidth and circuit sizes quickly become unmanageable.

The current CAC mechanism in place in the scenario is RSVP Call Agent.  This is largely because there are two CUCM 8.6 clusters that are leveraging EMCC and SAF between each other.

Any further ideas?

Please help us make the communities better. Rate helpful posts!

Hi Steven,

Thanks for your explanation in details.

At the beginning I though all on-net and off-net calls were thru CUBE. As in this situation all branch sites' phones are registered with and controlled by CUCM, the network would be as below:

Here the RTP stream of on-net call will be between two sites, and RTP stream of off-net call will be from site to SIP carrier directly.

Assume all off-net calls (to service provider) goes thru CUBE. I think location based CAC will meet most of the requirements:

- the bandwidth specified for one location (e.g. Site 1) will only allow limited calls, including on-net (inter-site) and off-net, it may have;

- all off-net calls (incluing inbound or outbound) can be limited by a separate location which assigned to SIP trunk for CUBE;

- other on-net calls, such as MeetingPlace, UCCX, Voicemail or intercluster call, would be considered as calls between branch site to HQ as most probably these servers are located at HQ.

Hope the above helps. Please let me know if you have any further questions.

Thanks,

Robin

Gaurav Purohit
Level 1
Level 1

Hello Robin,

I was wondering if you can point to the particular cases/scenarios where Media-flowthough and Flow-around are of particular importance?

do you need to specify the capabilities when using flow-around? (do we see SDP related information)

Also, in case of transfers(REFER), does the CUBE has visibility to CODECs in Flow-around?

Hello Gaurav,

Thanks for your question.

In most cases, media flow-through is used in order to  hide address and traverse NAT, as other equipments just communicate with  CUBE directly without being aware of the whole network behind CUBE.  Especially for enterprise VoIP network, you don't need to exposure the  internal network to carrier, instead just give the carrier the public  address of CUBE, which reduces the possibility of being hacked from  outside. Sometime even the internal network (192.X.X.X, 172.X.X.X..) is  not reachable from the carrier, you have to use the media flow-through  mode as CUBE is the device standing between two networks and it will  properly terminate and regenerate the media streams.

Another example would be to convert Multicast MOH to unicast MOH toward Service Provider side. Below is one typical topology:

Phone A---PSTN---(SIP)---CUBE---(SIP)----..WAN..---CUCM---Phone B

To  save the bandwidth, Multicast MOH is used between CUBE and CUCM. CUBE  has to use media through to make sure Phone A hear MOH if it is is put  on hold by Phone B.

Generally speaking media flow-around is applied in some cases  when you don't want to media streams go through CUBE due to bandwidth  limit or voice delay restrain.

When using flow-around, the  SDP related information is visible on CUBE. The codec or codec class  specified under dial-peer still work as it will filter out the  unsupported codecs.

The case of transfer(REFER), I think  you mean the REFER message is consumed on CUBE and CUBE initiates the  new call. In this case, CUBE is also aware of the codecs as it still  needs to match the dial-peer based on the REFER-TO number. If the REFER  message is passed thru to other devices on CUBE, that's easy as there is  only original call on CUBE, and new device will send RE-INVITE to  update the medial address/port via CUBE.

Hope above answers your questions. If you have other questions, please feel free to let me know .

Thanks and regards,

Robin

Hi

We have established sip trunk with the ISP and we have problem with incoming calls

Actually the calls never going to ipphone

i am wondering if you can help in a technical level

Call Flow:

ISP Sip trunk with vg-VG sip dial peer pointing to cucm-CUCM

Regards

chrysostomos

Please rate all useful posts Regards Chrysostomos ""The Most Successful People Are Those Who Are Good At Plan B""

Hi Chrysostomos,

Sure. At this momenet, we are not sure where the call is failing. In order to further investigate, could you please collect the following debug logs on CUBE:

debug ccsip message

debug voip ccapi inout

Alos please provide the running configuration of CUBE.

Thanks and regards,

Robin

Hi Robin

We have similar issue here as Chrysostomos mentioned, intermittent incoming call drop out on answer. I've been working this issue since Nov but no luck to fix it. All outgoing calls seem to be fine.

Call flow as below:

ITSP--SIP--CME--SIP-9971

Please advise how can i upload running config and debugs.

Regards

Fei

Hello Fei,

Thanks for your question.

I am not sure if your account has the privilidge of adding attachments or not. However there are some other ways as below:

1) compress all files to one zip, upload it to ftp://anonymous:cisco@ftp.cisco.com/incoming, then tell me the filename here.

2) upload your file to some share folder in internet, then give me the download link.

Once I get your debug log and config, will help you have a look.

Thanks and regards,

Robin

Hi Robin

I dont think my account has privillege fo adding. I tried to upload to url ur provide, i was asked to provide username/password for. Whether my cisco id should be use or something else.

Regards

Fei

Hi Fei,

You can log in this ftp server by using account annomyous (password can be anything). It's recommended to login and upload via CLI (window command line or unix/linux shell).

Thanks,

Robin