Hey guys,
In this post I will show you one situation I came across this week.
Due some attacks we’ve been suffering, we decided to get all blocked IPs on Expressway and block them also in the local Firewall, as a workaround while we investigate it better.
The thing is, how can we export the list of Banned IP addresses on Expressway?
As I didn’t find anything, I decided to do on my way, automating it.
Continue reading “Expressway – Exporting Banned addresses using PowerShell”
Hey guys,
Today I’m going to talk about a very useful solution, part of the Cisco Collaboration Edge Architecture: MRA.
This post is going to be the first part, to cover the concepts, requirements and compatibilities.
Basically, MRA (Cisco Unified Communications Mobile and Remote Access) allows endpoints such as Cisco Jabber to have their registration, call control, provisioning, messaging and presence services provided by CUCM when the endpoint is outside the enterprise network. The Expressway provides secure firewall traversal and line-side support for Unified CM registrations.
This solution supports a hybrid on-premises and cloud-based service model. It provides a secure connection for Jabber application traffic and other devices with the required capabilities to communicate without having to connect to a VPN. It is a device and operating system agnostic solution for Cisco Jabber clients on Windows, Mac, iOS and Android platforms.
MRA allows Jabber clients that are outside the enterprise to do the following:
Components
MRA requires Expressway (Expressway-C and Expressway-E) and Unified CM, with MRA-compatible soft clients and/or fixed endpoints. The solution can optionally include the IM and Presence Service and Unity Connection.
Product Versions
Protocols
Compatible Endpoints
If you are deploying any of these devices to register with Cisco Unified Communications Manager through MRA, be aware of the following points. For DX endpoints, these considerations only apply to Android-based devices and do not apply to DX70 or DX80 devices running CE software:
Trust list: You cannot modify the root CA trust list on Cisco IP Phone 7800 Series and Cisco IP Phone 8800 Series devices. Make sure that the Expressway-E’s server certificate is signed by one of the CAs that the devices trust, and that the CA is trusted by the Expressway-C and the Expressway-E.
Off-hook dialling: The way KPML dialling works between these devices and Unified CM means that you need Cisco Unified Communications Manager 10.5(2)SU2 or later to be able to do off-hook dialling via MRA. You can work around this dependency by using on-hook dialling.
CUCM dial plan will not be impacted by devices registering via Expressway. Remote and mobile devices still register directly to Unified CM and their dial plan will be the same as when it is registered locally.
Unified CM nodes and Expressway peers can be located in different domains. For example, your Unified CM nodes may be in the enterprise.com domain and your Expressway system may be in the edge.com domain.
In this case, Unified CM nodes must use IP addresses or FQDNs for the Server host name / IP address to ensure that Expressway can route traffic to the relevant Unified CM nodes.
Unified CM servers and IM and Presence Service servers must share the same domain.
Two certificates on CUCM are significant for Mobile and Remote Access: CallManager certificate and Tomcat certificate.
PS: If you do use self-signed certificates, the two certificates must have different common names. The Expressway does not allow two self-signed certificates with the same CN. So if the CallManager and tomcat self-signed certificates have the same CN in the Expressway’s trusted CA list, the Expressway can only trust one of them. This means that either secure HTTP or secure SIP, between Expressway-C and Cisco Unified Communications Manager, will fail.
The Expressway certificate signing request (CSR) tool prompts for and incorporates the relevant Subject Alternative Name (SAN) entries as appropriate for the Unified Communications features that are supported on that Expressway.
The Expressway-C server certificate must include the following elements in its list of subject alternate names: Unified CM phone security profile names and
IM and Presence chat node aliases (federated group chat)
The Expressway-E server certificate needs to include the following elements in its list of subject alternative names (SAN): Unified CM registrations domains, XMPP federation domains and IM and Presence chat node aliases (federated group chat)
That’s it for today guys….just an overview.
In the next posts, I’m going to go a bit deeper in the configuration.
Hope you’ve enjoyed!
See ya!
Bruno
Hey guys,
In my last post, I gave you some tips on how pull CDRs out from CUCM using SQL commands (Cisco CUCM – CDR through SQL). Today, I’m going to show other useful reports you can get using SQL commands.
As we are getting all the information from a CLI command, you will need to export the data to an excel file to create something nice to be presented….or even use Python, PHP, to create something automatic for you.
Today I’m going to focus on one command, but with different variables and outputs: show risdb
This command displays RIS database table information.
Parameters
• list : displays the tables that are supported in the Realtime Information Service (RIS) database.
• query : displays the contents of the RIS tables
So, if you enter the command show risdb list, you will see a list of options in the table that you can explore.
The most common, and used, is the Phone.
To access this table, you must use this command: show risdb query phone.
This command is so powerful and useful!!! Here we see everything related to your phones: DeviceName, Descr, Ipaddr, Ipv6addr, Ipv4Attr, Ipv6Attr, MACaddr, RegStatus, PhoneProtocol, DeviceModel, HTTPsupport, #regAttempts, prodId, username, seq#, RegStatusChg TimeStamp, IpAddrType, LoadId, ActiveLoadId, InactiveLoadId, ReqLoadId, DnldServer, DnldStatus, DnldFailReason, LastActTimeStamp, Perfmon Object.
In other words, you can have a list of devices in your Cluster, check each phone is currently Registered or Unregistered, and its information such as IP, Protocol, Model……an excellent Report 
But, if you want to explore it a bit more, there are other interesting queries!
For example, if you want to have a report about your SIP Trunks, you can use this command: show risdb query sip.
Here you have information about your SIP Trunk, such as name, IPs, descriptions, Status, Peer Status.
This is the Trunk on CUCM:
The Status column (in red) corresponds to the “Service Status” field visible near the top of CCMAdmin’s SIP Trunk page.
0 – No service (The Trunk peer is reachable via TCP, but SIP Options ping is failing)
1 – Full service (All Trunk peers are up and SIP Options ping is successful)
2 – Partial service (A subset of Trunk peers are unreachable)
3 – Unknown (The Trunk peer is unreachable via TCP, or SIP Options ping is not enabled)
The PeerStatus column (in blue) corresponds to the “Status” field for each peer on the SIP Trunk page (near the bottom).
0 – Down
1 – Up
Now it’s up to you to choose a query from RSIDB list and start to explore it. You will find interesting options there, like CTIs, Gateways…..
Hope you’ve enjoyed it
See ya!
Bruno
Hey everybody,
Today’s post is going to be quick, but may give you some good tips 
Last week I got some requests from a Customer, and he needed to know which extensions were recently being used . In order to save licenses, he wanted to delete all phones/lines that weren’t being used.
CDRs on CUCM is a nightmare in my opinion. Mainly when you need to check lots of lines, for a long period.
That’s why I decide to pull this information out directly from SQL.
So here are some useful commands to get CDRs from SQL, and depending on your needs and knowledge, you can use Python or other language to built your own CDR Reporting
First of all, to use the commands you need to ensure that the following steps are taken on your CUCM system:
Now, going to SQL, this is the structure of any SQL Command on CUCM:
admin: run sql select [field list] from [table] where [expression]
The table we are going to use is tbl_billing_data. This table stores all of the elements we need to accomplish the task at hand.
So this is going to be our syntax: run sql select + column + from tbl_billing_data + where + column + (like,in,between,etc).
PS: Please not this command is only acceptable on Publisher.
In my example, I want to get Date (TimeStamp) , Calling and Called Number of all calls from extensions which have “702709” in their numbers and happened this month.
The date must be sent in TimeStamp mode. I use THIS SITE to convert normal date to Timestamp, and vice versa. If you were pulling CDR data into Excel then you can use the following formula (in a new cell) to do the conversion:
=(((A1-(6*3600))/86400)+25569)
Right, so this is the command:
run sql car select datetimeOrigination,callingPartyNumber,finalCalledPartyNumber from tbl_billing_data where callingpartynumber like ‘%702709%’ and datetimeconnect > ‘1630486076’
And here is the result:
Well, now you can explore and play a bit more, depending on your needs. You can add more columns, like duration, destIpAddr, callingPartyNumber_uri, originalCalledPartyPattern,callingPartyNumberPartition,EU_SIP_SME_NOS….
That’s it guys. As I said, it was really quick
Hope you’ve enjoyed!
Bruno
Hey everyone,
Today I’m going to talk about a common issue that I believe you’ve already faced in your infrastructure.
One way audio happens when you have a call between 2 phones (internal-internal or internal-external), and one of them cannot hear the other end.
The causes of one-way audio in IP Telephony can be varied, but the root of the problem usually involves IP routing issues.
Possible causes for the one-way audio issue:
* RTP traffic is being blocked or consumed by a Firewall or another security device.
* RTP traffic is being misrouted by a route recently added / learned, or a VRF or WAN.
* Signalling issues – Call agent is not passing the correct ports or codec, or the communication is tagged as ‘send only’ or ‘receive only’.
* RTP traffic is corrupted.
* One side is not transmitting.
A quick way to check if there’s been audio during a call is by checking its statistics.
There are 2 ways to do that. Using Jabber/Deskphones statistics, or accessing Phone’s web page and checking also the statistics.
During a call, in your Jabber, press Crtl + Shift + S to open the call statistics. A pop up window like that will appear:
If you are not part of the call, you can check that through phone’s web page. Open it (using phone’s IP Address), and go to Stream 1 in the left menu. The whole statistic will come up in the middle. Check if the IP address and port match the information on both sides. Keep pressing the ‘stream 1’ link and you will notice that the TX and RX stats keep increasing.
Here you can check the ‘Local’ and ‘Remote’ IP addresses, then you see the port. If the information is the same on the other side, (‘Local’ on one side should correspond to the ‘Remote’ on the other), then signalling is good.
You can also check if the Coded used is the one you were expecting. If not, change the codec preference list or the available BW on the region.
Now, let’s have a look at some scenarios and solutions, and most common issues found in the field.
Some Cisco IOS gateways, such as the VG200, disable IP routing by default. This default setting leads to one-way voice problems.
Ensure that IP routing is enabled on your router. In order to enable IP routing, issue this global configuration command on your Cisco IOS gateway:
voice-ios-gwy(config)#ip routing
Always check basic IP reachability first. Because Real-Time Transport Protocol (RTP) streams are connectionless (transported over UDP), traffic may travel successfully in one direction but get lost in the opposite direction. This diagram shows a scenario in which this can happen:
Subnets A and B can both reach Subnet X. Subnet X can reach Subnets A and B. This allows the establishment of TCP connections between the end stations (A and B) and the Cisco Call Manager. Therefore, signalling can reach both end stations without any problems, which allows the establishment of calls between A and B.
Once a call is established, an RTP stream that carries the audio must flow in both directions between the end stations. In some cases, Subnet B can reach Subnet A, but Subnet A cannot reach Subnet B. Therefore, the audio stream from A to B always gets lost.
This is a basic routing issue. Use IP routing troubleshooting methods in order to get to the stage at which you can successfully ping Phone A from Gateway B. Remember that ping is a bidirectional verification.
If transcoding is configured for an Intercluster trunk (ICT), ensure that a Media Termination Point (MTP) is configured in the Media Resource Group and Media Resource Group List associated with the trunk. If you specify an MTP when one is not needed, or fail to configure an MTP if it is needed, it has been known to cause one way voice issues for ICT configurations.
When the Cisco IOS gateway has multiple active IP interfaces, some of the H.323 signalling may be sourced from one IP address and other parts of it may reference a different source address. This can generate various kinds of problems. One such problem is one-way audio.
In order to get around this problem, you can bind the H.323 signalling to a specific source address. The source address can belong to a physical or virtual interface (loopback). Use the h323-gateway voip bind srcaddr ip-address command in interface configuration mode. Configure this command under the interface with the IP address to which the Cisco Call Manager points.
One-way voice can occur in Media Gateway Control Protocol (MGCP) gateways if the source interface for signalling and media packets is not specified. You can bind the MGCP media to the source interface if you issue the mgcp bind media source-interface interface-id command and then the mgcp bind control source-interface interface-id command. Reset the MGCP gateway in Cisco Call Manager after you issue the commands.
If the mgcp bind command is not enabled, the IP layer still provides the best local address.
The guidelines for the mgcp bind command are:
* When there are active MGCP calls on the gateway, the mgcp bind command is rejected for both control and media.
* If the bind interface is not up, the command is accepted but does not take effect until the interface comes up.
* If the IP address is not assigned on the bind interface, the mgcp bind command is accepted but takes effect only after a valid IP address is assigned. During this time, if MGCP calls are up, the mgcp bind command is rejected.
* When the bound interface goes down, either because of a manual shutdown on the interface or because of operational failure, the bind activity is disabled on that interface.
* When bind is not configured on the Media Gateway Controller (MGC), the IP address that is used to source MGCP control and media is the best available IP address.
If you find that there are clock slips on the E1 or T1 interface from the show controller {e1 | t1} command, there might be some mismatch in the clocking configuration on the Voice Gateway.
Two useful commands to use in order to verify packet flow are the debug cch323 rtp command and the debug voip rtp command. The debug cch323 rtp command displays packets that are transmitted (X) and received (R) by the router. An uppercase character indicates successful transmission or reception. A lowercase character indicates a dropped packet.
voice-ios-gwy#debug cch323 rtp
RTP packet tracing is enabled
voice-ios-gwy#
!— This is an unanswered outgoing call. !— Notice that the voice path only cuts through in the forward direction and !— that packets are dropped. Indeed, received packets are traffic from the !— IP phone to the PSTN phone. These are dropped until the call is answered.
Mar 3 23:46:23.690: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXXrrrrrrrrrrrrrrrr
voice-ios-gwy#
voice-ios-gwy#
!— This is an example of an answered call:
voice-ios-gwy#
voice-ios-gwy#
*Mar 3 23:53:26.570: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XXrrrrrXrXrXrXrXrXrXrXrXrXrXrXrrXXrrXrXrXrXrXrXXXXXXXXXXXXXXXXrXXXXXXXXrXrXrXXrrXr
XrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
!— At this point, the remote end picks up the phone.
*Mar 3 23:53:30.378: ****** cut through in BOTH direction *****
XRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXR
XXRRXRXRXXRRXRXRXRXRXXRXRXRXRXRXRRXRXXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRXXRXRXRXRXRXRRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XXRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXXRRRXR
!— This is the end of the conversation.
Note: In Cisco IOS Software Release 12.2(11)T and later, the debug cch323 rtp command-line interface (CLI) command has been replaced by the debug voip rtp command.
voice-ios-gwy#debug voip rtp
——–cut through in BOTH direction——————-
*Mar 27 19:52:08.259: RTP(32886): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFBF0, ssrc=8E5FC294
*Mar 27 19:52:08.275: RTP(247): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00C8D9, ssrc=1F1E5093
*Mar 27 19:52:08.279: RTP(32887): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFC90, ssrc=8E5FC294
*Mar 27 19:52:08.295: RTP(248): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00C979, ssrc=1F1E5093
*Mar 27 19:52:08.299: RTP(32888): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFD30, ssrc=8E5FC294
*Mar 27 19:52:08.315: RTP(249): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CA19, ssrc=1F1E5093
*Mar 27 19:52:08.319: RTP(32889): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFDD0, ssrc=8E5FC294
*Mar 27 19:52:08.335: RTP(250): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CAB9, ssrc=1F1E5093
*Mar 27 19:52:08.339: RTP(32890): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFE70, ssrc=8E5FC294
*Mar 27 19:52:08.355: RTP(251): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CB59, ssrc=1F1E5093
*Mar 27 19:52:08.359: RTP(32891): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFF10, ssrc=8E5FC294
*Mar 27 19:52:08.375: RTP(252): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CBF9, ssrc=1F1E5093
*Mar 27 19:52:08.379: RTP(32892): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFFB0, ssrc=8E5FC294
*Mar 27 19:52:08.395: RTP(253): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CC99, ssrc=1F1E5093
*Mar 27 19:52:08.399: RTP(32893): fs rx d=10.48.79.181(20002),
pt=0, ts=500050, ssrc=8E5FC294
*Mar 27 19:52:08.976: RTP(282): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DEB9, ssrc=1F1E5093
*Mar 27 19:52:08.980: RTP(32922): fs rx d=10.48.79.181(20002),
pt=0, ts=501270, ssrc=8E5FC294
*Mar 27 19:52:08.996: RTP(283): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DF59, ssrc=1F1E5093
*Mar 27 19:52:09.000: RTP(32923): fs rx d=10.48.79.181(20002),
pt=0, ts=501310, ssrc=8E5FC294
*Mar 27 19:52:09.016: RTP(284): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DFF9, ssrc=1F1E5093
This is all for today.
I hope you’ve enjoyed 
See ya!
Bruno
Get Practical 