Cisco CUCM and WebEx Calling - Almost feature parity?
To mis-quote James Carville, Bill Clintons campaign advisor, "It's the features, stupid!"
Yes indeed when contemplating CUCM to WebEx calling migration, one of my long standing concerns was always feature parity, when WebEx calling first became a Cisco offering, the feature list was.... lacking, in comparison to the robust and comprehensive list of features you could get on CUCM (Now which kind of LICENSE you had to buy to get those features is another story...)
It takes a closer look at things like Hunt Groups (which often are more complicated than you might initially assume, especially when you start talking about no coverage options and different treatments for external vs internal calls), Call Queues, shared lines, Extension Mobility, and of course, Call Recording.
It is fair and correct to say: WebEx calling has come a LONG way, the vast majority of feature set required by 95% of your user base is now easily covered, and sometimes exceeded by the offerings from WebEx Calling (the call queueing functionality being a particular example, or the ability to build IVR or other call routing scripts without requiring Cisco Contact Center and all the FUN that introduces.)
As always however, there is some foot-guns to watch out for, one key take away for me was: Just because both WebEx calling and CUCM might list "hunt groups" on their feature list, does not make the knobs and dials you can fiddle with equivalent between the two platforms, and some of the features that offer very similar functionality may be invoked differently by your end users and require some mild retraining (very mild and short, think: hand out one-pager documents with little tips and tricks, or optional, 30 minute lunch demonstrations).
Of course, one feature we all know is important and for a long time got the short end of the stick when it came to feature parity. The call recording solution in WebEx calling, while it has its own issues such as a short retention period and other problems, has at least always been a native solution to WebEx Calling (and has not required you to deploy four Windows Server Standard Virtual machines, which is what you have to do for example when using a Calabrio (also known as verint) solution.
Luckily however, Call Recording dot com exists, and this is where call-recording.com makes sense for CUCM users moving to Webex Calling: supported recordings from both platforms can stay in one dashboard for call and message playback, this kind of usability of a unified dashboard is exactly the kind of thing your compliance officers care about, and it's understandable: Which HR staffer wants to worry about searching across two disparate systems for evidence in some misconduct allegation, the job is hard enough! A single unified interface like call recording offers makes this a lot easier, oh and it does not hurt at all either that their solution transcribes all calls no matter which platform (CUCM or WebEx Calling, even Microsoft teams!) you use. it DEFINITELY does not hurt that it auto tags and shows you exactly where in a call it suspects their have been incidents of bullying for example, or financial disclosures.
Another great blog post on the Call Recording blog. That covers the in's and out's of migration from CUCM to WebEx calling when it comes to Directory Connector, Microsoft Entra ID, Okta, and all the other directory services out there.
It's obviously best practice where possible to have a single source of truth and one authoritative directory source for users, groups and endpoints. No one wants to deal with duplicate identities, mismatched email addresses or domains, all of that just makes the fairly involved but doable process of migrating to WebEx calling turn into a nightmare. However, what DOES feel unreasonable for a long time Cisco UC engineer like me is the devil in the detail of their "migration-tool": Cisco's native CUCM migration path assigns Professional or CX Essentials licenses, while Standard licences need a different CSV-led route. Come on Cisco! What the heck is this? "Some Licensed users are more equal than others?" to misquote Animal farm.
The blog post gives a few hints to make life a bit easier though: Do the identity work first. Match CUCM end users, Control Hub users, email addresses, UPNs, numbers, and licences before moving phones.
Pick your Directory Connector, Entra provisioning, or Okta deliberately rather than stacking sync engines until users begin reproducing. Also worth remembering, Call Recording and message archival for compliance recording and archiving makes this even more important: Your call recording solution, which of course, should be call-recording.com, needs the migrated conversation associated with the right end user in the call recording dashboard, that way the old CUCM call and the new Webex Calling call do not look like they belong to two different users.
# Webex Calling PSTN: The Cloud Does Not Make Dial Plans Disappear
Hi Guys!
There is a great new post on the Call Recording blog, addressing a task becoming more and more common for my fellow UC engineers, CUCM To WebEx Calling migration!
The fact is the writing is on the wall: Cisco are about as subtle as a Bull, and yet there is no subtly in their obvious push to get everyone off premise and on to their UCaaS platform. I think their terrible handling of the CUCM 15 upgrade roll out, (complicated for everyone by the broadcom purchase of VMWare and its subsequent impact on UC hosted on ESXi!) along with their terrible handling of the recent retirement of the TLS client extended key usage property for publicly signed certs.
The Webex Calling PSTN strategy guide, goes through Cisco CUCM to WebEx Calling migration and what you need to think about from a PSTN connectivity perspective when migrating. You have lots of options such as Cisco First-Party offered PSTN connectivity, Cloud Connected PSTN, or CUBE Local Gateway.
From a Cisco engineer's point of view, offering all three is reasonable. Different countries, carriers, emergency-calling rules, and existing contracts make one universal PSTN answer impossible. What is less reasonable is pretending that "cloud PSTN" is the default and always selected option. while it can lead to (slightly) easier number porting (always a nightmare), caller-id and some failover solutions, it's got some drawbacks the article goes into that are worth considering, especially in regards to analog devices and emergency calling.
Ultimately I think the best way to approach this problem is to pick your connectivity per location, not a one-size-fits all option that is meant to work for the entire company.
Like the article mentions, none of this matters if your test plan sucks, it's not just about testing a variety of different numbers like local, long distance and International, but on the type of call scenario, example: actual inbound, outbound, transferred, call pickup group, call forward, call parked. etc. etc. Of course! I would be remiss not to mention, you should probably test you're correctly recording the calls too (Call Recording offers the best solution for this hands down, it's a no brainer!).
I have spent my career as a network engineer and earned three CCIE certifications. That background shapes how I think about call recording. Hence, a family member has started: Call Recording, a Cisco CUCM, WebEx and Microsoft Teams call recording and compliance recording for Unified compliance archival and recording of both calls and message history across the two major platforms (Cisco CUCM and Webex along with Microsoft Teams)
I have seen plenty of products that look simple in a presentation but become complicated the moment they touch a real production network. The proposal says “call recording.” The implementation turns into a professional-services engagement, a large firewall request, new appliance pairs, database licences, weeks of coordination, and a Statement of Work just to produce the first playable recording.
I did not build call-recording.com to reproduce that model in a browser.
I built it around a different idea: call recording should be an operational system, not an appliance project.
That means setup should be self-service. Security should be understandable. Recording delivery should survive failures. Health should be measurable. Pricing should be predictable. Privacy should be explicit. Most importantly, the system should prove that a call was actually recorded—not merely report that a recording service appears to be running.
A recording is more than an audio file
A real call-recording workflow is a chain of events.
The phone system must apply the correct recording configuration. Media must reach the recorder. Call metadata must identify the correct participants. Audio must be preserved locally, delivered successfully, associated with the right call, indexed, and made playable to an authorised user.
If any part of that chain fails silently, the organisation may not discover the missing evidence until it is already needed for an audit, dispute, investigation, or customer complaint.
That is why I care so much about end-to-end validation.
A green service icon is not proof that calls are being recorded. A received SIP session is not proof that the audio was safely delivered. A CUCM Call Detail Record is valuable, but CDR data describes a call—it does not contain its audio.
For me, the meaningful finish line is straightforward:
The call was captured, journaled, delivered, indexed, and is playable by the right person.
Everything else is an intermediate status.
From signup to a validated recording
Traditional enterprise recording deployments can take weeks because the customer must wait for sales engineering, professional services, installation scheduling, firewall approval, and vendor-led configuration.
The guided setup workflow discovers the customer’s Cisco environment, recommends a design, and waits for approval before applying changes. It can work with recording profiles, Built-In-Bridge settings, SIP trunks, device configuration, and different recording modes.
The important word is guided.
Automation should not mean hiding changes from the engineer responsible for the environment. The platform can use AI to assist with discovery and recommendations, but the administrator still approves the design, and the final verification comes from a human placing a real call.
The workflow also checks the existing environment before creating resources. If an appropriate SIP trunk already exists, the goal is to reuse or safely update it—not create a duplicate and leave the customer to clean up afterwards.
That is the standard I want for self-service infrastructure: fast, visible, repeatable, and grounded in the real configuration.
The firewall request should fit on one line
Security architecture matters before a single call is recorded.
Many traditional recording systems require broad RTP ranges, inbound management interfaces, port forwarding, and multiple bidirectional rules. Every exposed service creates another item for the network and security teams to approve, monitor, patch, and defend.
The call-recording.com recorder uses internal access to the Cisco systems it serves and one simple internet rule:
Outbound TCP 443 to call-recording.com.
There are no inbound internet rules, no published recorder-management interface, no port forwarding, and no enormous UDP range exposed to the outside world. The recorder works behind NAT and, in many environments, through an existing web proxy.
That is not merely convenient. It is a deliberate low-footprint design that aligns with modern Zero Trust Network Access principles.
As a network engineer, I believe a product should make the security change request smaller—not ask the customer to accept unnecessary exposure because “that is how call recorders have always worked.”
A WAN interruption should not become a missing recording
Cloud-connected systems must be designed for imperfect networks.
If the WAN drops, the recorder should not discard calls, lose track of what it captured, or depend on someone manually restarting an upload process. Audio and call details should remain locally protected and journaled until the service is reachable again.
When connectivity returns, durable retries should continue from where delivery stopped.
This is why local persistence and accountable delivery are central to the architecture. A recording is not treated as complete simply because it was written to a temporary file. The delivery path must keep track of what was captured, what was delivered, and what still needs attention.
Integrity matters too. Encryption, checksums, tamper detection, audit history, and controlled retention help establish that a recording remained intact and that access to it was accountable.
The same philosophy applies to operational alerts. Recorder, SIP, and AXL health are different signals and should be reported separately. If an instance stops sending heartbeats, the platform should generate a durable outage notification rather than relying entirely on a temporary browser or WebSocket connection.
Useful alerts should say which recorder is affected, which address it uses, which servers were attempted, and which checks failed. “Something is down” is not enough information for the engineer expected to fix it.
Recovery is equally important. The platform should report when service returns, not leave an unresolved outage notification hanging after the system has healed.
Deployment should match the customer’s infrastructure
Customers should not have to redesign their infrastructure around a recording vendor’s preferred appliance.
The recorder is designed for containers, common hypervisors, cloud compute, and supported Cisco edge platforms. That includes practical deployment paths for Docker, VMware, Hyper-V, Nutanix, Proxmox, KVM, Xen, AWS, Azure, and Google Cloud.
The setup experience should present everything needed at once: the recorder identity, deployment command, configuration, and claim workflow. Customers should not be forced through unnecessary “Generate” buttons or disconnected pages to assemble one usable command.
Recorder claiming is also treated as a security boundary. Device-code registration is the primary workflow, and even alternate instance-based claiming must be backed by a real, short-lived registration record. Knowing or guessing the shape of an instance identifier should never be enough to claim infrastructure.
The downloadable artifact itself is part of the product contract. Correct filenames, published checksums, and independent verification matter because “the build succeeded” is not the same as “the customer can safely download and deploy it.”
Capacity should be arithmetic
Traditional recorder growth often means purchasing larger appliances, adding active/standby pairs, expanding a local database, or scheduling another vendor-led upgrade.
The call-recording.com recorder is intentionally lightweight and stateless. Each node contributes capacity independently, so scaling is a matter of adding another node rather than replacing an appliance.
A typical 4 GB, 2 vCPU recorder node can support up to 512 concurrent calls, depending on codec and workload. Up to 16 stateless nodes can be distributed behind a SIP trunk, allowing an architecture to approach 10,000 concurrent calls without turning growth into a forklift project.
That model also fits the way real voice environments are organised. Capacity can be placed near the phone systems and media sources it serves instead of forcing every location through one oversized central appliance.
CUCM depth still matters
Simple deployment should not mean shallow Cisco support.
Cisco call recording involves more than opening a media port. Recording profiles, line appearances, Built-In-Bridge behaviour, SIP trunks, device pools, media resource groups, recording modes, gateway-based recording, multi-fork designs, CUBE, AXL, RisPort, CDR, and CMR data all affect the final result.
The platform is built to understand those operational details.
It can help administrators discover CUCM clusters, apply recording settings in bulk, identify offline devices, monitor job progress, and produce row-by-row results when a large change does not complete perfectly. Existing configuration is inspected before it is modified, and current SIP destinations are preserved when the recorder must be added to an established trunk.
That level of detail matters because voice networks are rarely blank-slate environments.
The platform also supports Cisco Webex and UCCX workflows, while the broader integration architecture is being extended to approved workplace communications such as Microsoft Teams. Features that are still being proven should be clearly marked as beta rather than presented as finished simply because a navigation link exists.
Compliance begins with notice, policy, and control
No call-recording platform can declare an organisation compliant simply because it captured audio.
Recording laws vary by jurisdiction. Some locations permit one-party consent, while others require notice or consent from every participant. Remote employees and interstate calls make the analysis more complicated.
Our Guide to Call Recording Laws explains the practical starting point: tell people before recording, make the notice consistent, define what is recorded, and review the policy with qualified legal counsel.
The technology should then make that policy enforceable through:
Role-based access to playback, download, export, and deletion
Configurable recording modes and disclosure workflows
Retention and legal-hold controls
Audit trails for access and administrative activity
Searchable call metadata and recordings
Pause-and-resume controls for sensitive conversations
Clear ownership of organisation and user access
Reliable evidence that the configured policy was actually followed
Monitoring should also stay within defensible boundaries. Business systems and approved company channels are different from personal accounts and private life. Our Workplace Messaging Guide reflects that balance between legitimate organisational recordkeeping and employee privacy.
Private data should remain private
Call recordings can contain customer information, financial details, health information, internal discussions, and other sensitive material.
That data should not become advertising inventory.
The call-recording.com Privacy Policy states this directly: we do not sell personal data, call recordings, call metadata, or organisation data to advertisers, and we do not use recording content to build advertising profiles.
Privacy should be expressed in plain language and reinforced by the product architecture. Authentication, verified organisational ownership, role-based permissions, audit records, protected internal services, encryption, and controlled retention all contribute to that goal.
Customers should understand what the service collects, why it is needed, where their recordings go, and who can access them.
That should not turn every invoice into a forensic exercise.
call-recording.com pricing is based on user licences rather than recorded calls, recorded minutes, or retained gigabytes. There are no usage-based charges for ordinary call volume and no setup or professional-installation fee.
The goal is a bill that remains understandable when call volume rises—not an invoice filled with surprise overages.
Customers can evaluate the complete workflow during a 30-day trial, using their own Cisco environment, without providing a credit card. The trial should prove whether the platform works before the customer is asked to select a paid plan.
Built for the engineer who has to live with it
I care about how the platform looks, but I care even more about whether its status reflects reality.
I care whether the recorder survives an interruption, whether a failed call can be traced, whether a deployment artifact is verifiable, whether an alert contains useful context, and whether the customer can reproduce what happened from the audit trail.
I care about the exact contract between CUCM, the recorder, the cloud service, and the dashboard because that is where production failures hide.
Most of all, I believe enterprise call recording should be testable in the customer’s real environment without months of meetings or a paid implementation project.
That is the idea behind call-recording.com:
Self-service without hiding the engineering
Automation with human approval
One outbound security rule instead of a sprawling firewall change
Local resilience with accountable delivery
Horizontal capacity without appliance upgrades
Deep Cisco operational support
Privacy without advertising exploitation
Compliance controls without pretending software replaces legal review
Predictable pricing without usage surprises
Real validation instead of dashboard theatre
If that is how you believe call recording should work, start a 30-day trial and validate it using your own phones, your own CUCM environment, and your own calls.
No credit card. No setup fee. No professional installation.
H.323 gateways don't support PLUS dialing in any way shape or form.. never knew that!
i.e. + in the display
Debugging Voice.
Ok, we all want our CCIE Voice numbers, I imagine that’s why a heck of a lot of you are reading this blog ;). I want mine too believe me… Double CCIE is the goal this year, 4 by 2012. Will I make it? I guess I’ll see.
Moving on, in the CCIE Voice lab we have all already been warned: Expect tons of troubleshooting. Internetworkexpert’s coursework would have you believe that this is limited to simple stuff like phones in the wrong VLAN and stuff like that, IP Expert seem to take a much better approach that chances are it’s going to be more complicated.
Cisco themselves mentioned at Networkers in Las Vegas that the CCIE Voice lab will now have lots of focus on troubleshooting, up to 15 percent! They also specifically mentioned that the days of assuming your PSTN is going to be an E1 connection in the lab are long gone too (i.e. it may entirely be a SIP trunk or H.323 gatekeeper.)
With this in mind, I set out on a journey of discovering voice troubleshooting, what followed was learning some incredibly useful commands that I wanted to share with you all.
We are going to examine some SIP call flows, some H.323 call flows and some DTMF-relay in an effort to understand them all a bit better. I have never seen an absolutely comprehensive collection of all this info in one place. I truly hope this helps someone out there.
This tutorial assumes you have some basic SIP knowledge already, you should know about the different types of SIP messages (invite, OK, ACK) , the fact that its text-based, that it sends back error codes as 400’s or 500’s like a HTTP server (404 not found, 403 unauthorized, that sort of thing.) Its also important to note (and I think Mark snow who used to be at IP expert for clearing this up in his VOD) that the UAC and UAS terminology you always see in SIP makes it sound way more complicated than it is: A UAC is just the “Calling” party and the UAS the called party. Simple as that.
All testing assumes a SIP trunk between a CUCM and a CUCME. Our CUCME has IP address 1.1.1.1 and binds all its SIP media to this address. Our CUCM has the IP address 10.0.0.252. Finally we have a phone with the IP Address 192.168.10.21 registered to our CUCM.
The CUCM handset has the number 5008, the CUCME has the number 911
First call debug:
In this example I am going to make a simple call from my CUCM handset
G.711, our device “911” will call “5008”
Source address of CCME: 1.1.1.1
SIP Trunk Details: Standard SIP trunk in CUCM. Nothing special configured,
SIP CALL FLOW current dial-peer:
dial-peer voice 9999 voip
destination-pattern 5...
session protocol sipv2
session target ipv4:10.0.0.252
codec g711ulaw
---- Digits Dialed on handset here ----
PeterCCIE18371#debug ccsip messages
SIP Call messages tracing is enabled
PeterCCIE18371#
Aug 24 14:10:45.879: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:5008@10.0.0.252:5060 SIP/2.0
This part might look fairly obvious. We are SENDING an invite to sip:5008@10.0.0.252, one of the key things I wanted to point out in this was the “Sent” command you see at the top, it can get extremely tricky when debugging SIP working out who sent what message, this should help clarify things a little.
The “Via” message helps us work out what IP Address we are sending out FROM, here you can see we have bound our SIP messages to send out as 1.1.1.1 (we used the bind command in our config previously)so this is a great way to work out where exactly your SIP messages are being sourced from.
Here we run into one of those things that makes it tricky to read SIP, you see here that even though we generated this message (the invite message) we have our phone (911) listed as a REMOTE PARTY? Well, to the server (the UAS, the CUCM that we are calling) we ARE the remote party. So again, important to pay attention to that bit right at the top that tells you if your sending or receiving this message. You will also note since we have only just sent this message we don’t have the display name for the number we are calling (5008) shown yet. We also have a “tag” which helps us identify messages related to this call.
The “Supported” keyword indicates the SIP features we support, in here we have timer refreshes and a few other bits and bobs. We also have a Min-SE which specifies our session interval and when it needs to be refreshed.
Here we are saying “This is the type of device I am” (user-agent) (essentially, although its not always the case) and the allow shows all the SIP methods that we understand and support. Subscribe for example indicates we support presence.
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1282659045
Contact:
Expires: 180
Here we can see that we are specifying a max forward, this says how many times we will allow this call to be forwarded (how many proxies or gateways in the path) we also have a Contact field, this tells the UAS where to send the message back to when its ready to send return messages.
Allow-Events: telephone-event
Supported: precondition
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 206
This is one of the more important parts of the messages and one of the least understood. In SIP some messages will contain SDP information (session description protocol) this is the information SIP that is actually used to control things like codec negotiation, dtmf-relay and also what IP addresses media should actually be sent to (this will become important later.)
v=0
o=CiscoSystemsSIP-GW-UserAgent 391 9124 IN IP4 1.1.1.1
s=SIP Call
c=IN IP4 1.1.1.1
t=0 0
a=rtr
m=audio 17922 RTP/AVP 0 19
c=IN IP4 1.1.1.1
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20
We have a lot of confusing looking attributes here so lets try and go through as many as we can, the “C” attribute you can see listed here tells the system who initiated the call, this will come to be important later. The M indicates what codec we want to use, and the attributes specify our dtmf-relays.
Aug 24 14:10:45.899: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Here you see we “RECEIVED” a message back from the other end, the content length is 0, indicating there is no SDP in this message. We also see that it is sending 200 trying, which essentially means its received our request. This is an important message: If the gateway does not receive this message after sending a 101 invite within the “Trying” timeout, it will retry X number of times and if no response is received will inform the gateway. These timers can be changed under SIP-ua with:
Sip-ua
Timers trying
Retry
!
You might need to do this if you have two CUCM’s as I posted in a previous blogpost.
Aug 24 14:10:45.903: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Now we are getting a little further, The other end has successfully found the number we have rung and is proceeding to ring on the handset. This message will be the last message you see until someone picks up the handset, this message times out OR they ignore you, redirect you or heck they just answer the call, whatever the case may be. We can see here at this point that the remote end has also let us know what capabilities (sip methods) this device supports. The content length is again 0 indicating that no SDP is sent with this message.
----- Call Answered Here --------
Aug 24 14:11:32.523: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
This is what we have been waiting for! The handset has picked up so we have been sent a 200 OK message with important details for us to connect the media streams up with.
To: ;tag=bb6a91cf-cec8-42ad-9aa3-7bda337c86c4-30307968
Contact:
Content-Type: application/sdp
Here we can see we have a content length of 155 indicating there is an SDP message waiting and a content-type of application/sdp, we also see above a keyword Supported: replaces, this is one of the many RFC extensions to SIP and is to do with conferencing, these all become more important as we perform call-forwards and other activities.
Here we see values for the session expire, 1800, indicating that a session refresh must occur during this time period. The responsibility of the refresher is also shown (the UAS)
v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.0.0.252
s=SIP Call
c=IN IP4 192.168.10.21
t=0 0
m=audio 22782 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
Here we see the SDP sent from the CUCM, as you can see we have less options in the RTP map, and we also have M for the media shown, you will also notice the c= IN IP4 showing the actual IP address of the handset itself. This is very important as this is where we will actually attempt to connect via RTP to. This address would change if you where using an MTP for example. Notice also the bit I have highlighted in red, this is the port number that the RTP will attempt to connect on. If you check the SDP we originally sent in the invite message this is our RTP port too
Aug 24 14:11:32.535: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Hidden away in all of this, is where we have actually been transfered to, the P-preffered-Identity: shown above shows where the forward is sent, Can you see where we have been transferred to?
If you said 5111, good on you!
Aug 24 14:55:12.063: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Again we have the extremely confusing thing where the “From: “ listed is actually a separate number to us, it’s very difficult to read if you look at this to try and determine which side has sent the message, use the Sent: or received at the very top to work out who sent what message. Here we are sending a 107 Invite which is a special type of message.
Aug 24 14:55:12.063: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
o=CiscoSystemsSIP-GW-UserAgent 2272 8359 IN IP4 1.1.1.1
s=SIP Call
c=IN IP4 1.1.1.1
t=0 0
m=audio 16950 RTP/AVP 0 19
c=IN IP4 1.1.1.1
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20
Here we are sending the CUCM our IP address and RTP stream that we will be listening on, the CUCM is responsible for relaying this information to the transferred-to party.
Aug 24 14:55:12.271: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Here we received a message back telling us no problem and where we need to connect to with our RTP stream, can you work out where we will be connecting to?
Here is another hint if you can’t get it from the above:
We can finally do our show sip-ua calls for more info, note that annoyingly, even though our display on our phone has updated to indicate we are calling 5111, the number shown in the sip-ua calls is still 5008
There you have it, if you made it this far, well done! I am glad to see your dedication. Why don’t you try debugging with G.729, try with an MTP clicked on your CUCM trunk and you will see things like the IP address for the rtp stream changed, the RTP-map will change depending on what dtmf-relay you want to do and much more.
