TEAMS Direct routing - no audio

[richard.priest]

Hi,

Currently configuring TEAMS direct routing to our on prem CUCM cluster via an ISR4451.

We've followed this guide / document 

https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/interoperability-portal/direct-routing-with-cube.pdf

and whilst we can connect a call fine and I see all the SIP messages i.e. Invite, 100, 180, 200 OK and ACK, we get no audio whatsoever.

We have an MTP doing transcoding, but can't work out why the audio isn't getting to either side. 

Any tips on debugging this? I'm OK on the CUBE, but a but lost on the MTP. That said I can see the call in progress when I run

show voip rtp connections 

Any help much appreciated

Cheers

[richard.priest]

removing the MTP requirements simplifies the routing, but my understanding of the MTP is the traffic to from the CISCO handset goes to the MTP, in a hairpin fashion?

Just to re-iterate, I really appreciate the assistance!

logs are attached

EDIT: Missed the sanitised CUBE config

[Scott Leport]

Thanks Richard for supplying these. 

Upon checking your configuration and debugs, the CUBE is using binding all signalling and media to your Gi0/0/3 interface and if you're sending the call to CUCM, I don't think that's what you want.

I am wondering if you would consider making the following changes:

sip
no bind control source-interface GigabitEthernet0/0/3
no bind media source-interface GigabitEthernet0/0/3

dial-peer voice 1000 voip

 voice-class sip bind control source-interface GigabitEthernet0/0
 voice-class sip bind media source-interface GigabitEthernet0/0

dial-peer voice 80000 voip

 voice-class sip bind control source-interface GigabitEthernet0/0
 voice-class sip bind media source-interface GigabitEthernet0/0

Shouldn't need to do anything with the rest of the dial-peers as the Tenant is applied and that's configured for interface binding.

[richard.priest]

Hi Scott, 

I've tried this config change as you've suggested, unfortunately it doesn't seem to have made any difference.

debug attached

[Scott Leport]

Thanks Richard,

That's a pity! However, the binding is looking right in these debugs. 

OK, so if we're sending the calls from Teams -> CUBE -> CUCM -> CUBE -> PSTN, have you reviewed the following doc? Not quite the same detail as the direct routing doc, but does outline what configurations would need to be in place on the CUCM SIP trunk.

https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/interoperability-portal/direct-routing-for-communications-manager-via-cube.pdf

Have you also tried bypassing CUCM when dialling out from Teams? What about incoming calls from the PSTN, do you experience the same audio issues on inbound too?

[richard.priest]

Hi Scott, just for a follow-up, kinda worked out what the issues were.

Discovered you can pull a PCAP from IOS-XE, which as soon as i viewed in Wireshark the issue was obvious. the audio stream was coming from the inside interface of the CUBE rather than the outside.

I added a NAT rule and relevant ACL's to the firewall and I have 2 way audio! Well I do to internal CUCM phones, if I call externally it's 1 way audio :-S I'm not hearing the audio from TEAMS but am hearing from the mobile device.

Question though, how to I force the audio stream to source from the 'outside' address? I thought binding would do that but it didn't seem to help when I tried. I don't think it's ideal having two different IP's being NAT and is probably the cause of the 1 way audio

[Roger Kallberg]

Are you 100% sure that the call uses the dial-peer that you want it to do? The bind statements on the dial-peer should be what is defining what IP should be used to source the traffic.

[Roger Kallberg]

Looking at your shared config and if I understand it correctly isn't this what you have?

Tenant 200 is the one that points towards Microsoft if I read your configuration correct. That has the bind statment for media to GigabitEthernet0/0/0. Isn't that your inside interface? You're also missing a bind for control on the tenants, you should add that.

If tenant 200 is used towards Microsoft and you want to source that from your outside interface you would need to make this change.

voice class tenant 200
bind media source-interface GigabitEthernet0/0/3
bind control source-interface GigabitEthernet0/0/3

[richard.priest]

Thanks Roger, I spotted that earlier, made the change and it worked and then saw your response! Apologies, but also thank you for confirming!

Also really appreciate the extra detail you added in the response, really helps me learn, thank you.

[Roger Kallberg]

Your welcome and glad to hear that you got it to work.

[Scott Leport]

Glad you have a fix Richard, but there are a few points / queries I'd like to raise.

"Discovered you can pull a PCAP from IOS-XE" - I asked if you had done this earlier on in the thread and your response was that the traffic was coming in through the Firewall / CUBE ok. Based on your response, I did not pursue that line of enquiry any further.

"You're also missing a bind for control on the tenants, you should add that." - @Roger Kallberg can you elaborate on that please? In the shared config I can see that the binding is configured on the tenants, it's just perhaps it was set to the wrong interface!

"I added a NAT rule and relevant ACL's to the firewall and I have 2 way audio!" - That makes sense as one way / no way audio issues are usually caused by NAT and Routing issues!

Also the direct routing document assumes there are 2 seperate connections, one for the SIP trunk to the ITSP and one for the SIP trunk to Teams. Of course, the traffic to Teams can use the same path as your SIP trunk to the ITSP, but according to the configuration supplied that was not the case, so I'd made suggestions configuration changes based on that.

[Roger Kallberg]

@Scott Leport The shared configuration had this.

voice class tenant 200
  srtp-crypto 1
  localhost dns:<fqdn here>
  session transport tcp tls
  no referto-passing
  bind media source-interface GigabitEthernet0/0/0
  pass-thru headers 290
  no pass-thru content custom-sdp
  sip-profiles 200
  sip-profiles 290 inbound
  early-offer forced
  block 183 sdp present

It and the other tenant also only have the bind statement for media. It’s missing the bind statement for control, aka signaling. See my other response for details on how to configure this. 

[richard.priest]

---

@Scott Leport wrote:

Glad you have a fix Richard, but there are a few points / queries I'd like to raise.

"Discovered you can pull a PCAP from IOS-XE" - I asked if you had done this earlier on in the thread and your response was that the traffic was coming in through the Firewall / CUBE ok. Based on your response, I did not pursue that line of enquiry any further.

Inexperience on my part, I could see lots of traffic passing the firewall, I wrongly assumed that this was also the media traffic as well as the control traffic.

What also threw me is that despite all syslogs being enabled I wasn't seeing any drops to the destination 52.114.0.0/14 and 52.112.0.0/14 subnets, if I'd have seen at least one drop I'd have had a telltale to follow. 

Apologies for providing a bit of duff info and leading us down the garden path so to speak. I am learning - slowly!

[richard.priest]

"Perhaps you need an additional rule within profile 200 to cover the IP address of the MTP? You could try taking MTP out of the RTP path altogether and see if that works?"

I'm not great with this as you can probably tell, what sort of rule do you mean?