Re: TEAMS Direct routing - no audio

richard.priest · ‎03-02-2021

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

Scott Leport · ‎03-02-2021

Hi there,

Do you have a Firewall upstream of your CUBE? If so, have you turned off SIP ALG?

In addition to this, do you have the SIP Profiles applied correctly?

richard.priest · ‎03-02-2021

Hi Scott,

Yes it goes via a firewall, SIP inspection is disabled.

Profiles are set correctly AFAICT

copied below (NAT also at play hence the additional rules) I've replaced the IP addresses & FQDN FWIW.

!
voice class sip-profiles 100
rule 10 request ANY sdp-header Audio-Attribute modify "a=sendonly" "a=inactive"
!
voice class sip-profiles 200
rule 10 request ANY sip-header Contact modify "@10.10.10.10:" "@fqdn_here:"
rule 20 response ANY sip-header Contact modify "@10.10.10.10:" "@fqdn_here:"
rule 30 request ANY sip-header SIP-Req-URI modify "sip:(.*):5061 (.*)" "sip:\1:5061;user=phone \2"
rule 40 request ANY sip-header User-Agent modify "(IOS.*)" "\1\x0D\x0AX-MS-SBC: Cisco UBE/ISR4451/\1"
rule 50 response ANY sip-header Server modify "(IOS.*)" "\1\x0D\x0AX-MS-SBC: Cisco UBE/ISR4451/\1"
rule 60 request ANY sdp-header Audio-Attribute modify "a=sendonly" "a=inactive"
rule 70 response 200 sdp-header Audio-Connection-Info modify "0.0.0.0" "1.2.3.4"
rule 71 response ANY sdp-header Connection-Info modify "IN IP4 10.10.10.10" "IN IP4 1.2.3.4"
rule 72 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.10.10.10" "IN IP4 1.2.3.4"
rule 73 request ANY sdp-header Connection-Info modify "IN IP4 10.10.10.10" "IN IP4 1.2.3.4"
rule 74 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.10.10.10" "IN IP4 1.2.3.4"
rule 80 request ANY sdp-header Audio-Attribute modify "(a=crypto:.*inline:[A-Za-z0-9+/=]+)" "\1|2^31"
rule 90 response ANY sdp-header Audio-Attribute modify "(a=crypto:.*inline:[A-Za-z0-9+/=]+)" "\1|2^31"
rule 100 request ANY sdp-header Audio-Attribute modify "a=candidate.*" "a=label:main-audio"
rule 110 response ANY sdp-header Audio-Attribute modify "a=candidate.*" "a=label:main-audio"
!
!
voice class sip-profiles 280
rule 10 request ANY sip-header User-Agent modify "(IOS.*)" "\1\x0D\x0AX-MS-SBC: Cisco UBE/ISR4451/\1"
rule 20 response ANY sip-header Server modify "(IOS.*)" "\1\x0D\x0AX-MS-SBC: Cisco UBE/ISR4451/\1"
rule 30 request INVITE sip-header SIP-Req-URI copy "@(.*:5061)" u01
rule 40 request INVITE sip-header From copy "@(.*)>" u02
rule 50 request INVITE sip-header Refer-To copy "sip:sip.*tls(;.*)>" u03
rule 60 request INVITE sip-header Refer-To remove
rule 70 request INVITE sip-header SIP-Req-URI modify "sip:\+AAA@(.*tls)" "sip:\1\u03"
rule 80 request INVITE sip-header SIP-Req-URI modify "sip:\+AAA" "sip:+"
rule 90 request INVITE sip-header History-Info modify "<sip:\+AAA@" "<sip:"
rule 100 request INVITE sip-header History-Info modify "<sip:\+AAA" "<sip:+"
rule 110 request INVITE sip-header To modify "<sip:\+AAA@(.*)>" "<sip:\u01>"
rule 120 request INVITE sip-header To modify "<sip:\+AAA(.*)@.*>" "<sip:+\1@\u01>"
rule 130 request ANY sip-header Contact modify "@.*:" "@\u02:"
rule 140 request ANY sip-header Via modify "SIP(.*) 10.10.10.10(.*)" "SIP\1 1.2.3.4\2"
rule 150 request INVITE sip-header Requested-By modify "sip:10.10.10.10>" "sip:1.2.3.4>"
rule 160 request ANY sdp-header Audio-Connection-Info modify "10.10.10.10" "1.2.3.4"
rule 170 request ANY sdp-header Connection-Info modify "10.10.10.10" "1.2.3.4"
rule 180 request ANY sdp-header Session-Owner modify "10.10.10.10" "1.2.3.4"
rule 190 response ANY sdp-header Audio-Connection-Info modify "10.10.10.10" "1.2.3.4"
rule 200 response ANY sdp-header Connection-Info modify "10.10.10.10" "1.2.3.4"
rule 210 response ANY sdp-header Session-Owner modify "10.10.10.10" "1.2.3.4"
!
voice class sip-profiles 290
rule 10 request REFER sip-header From copy "@(.*com)" u05
rule 20 request REFER sip-header Refer-To modify "sip:\+(.*)@.*:5061" "sip:+AAA\1@\u05:5061"
rule 30 request REFER sip-header Refer-To modify "<sip:sip.*:5061" "<sip:+AAA@\u05:5061"
rule 40 response ANY sip-header Server modify "(IOS.*)" "\1\x0D\x0AX-MS-SBC: Cisco UBE/ISR4451/\1"
rule 50 request ANY sdp-header Audio-Attribute modify "a=ice-.*" "a=label:main-audio"
rule 60 request ANY sdp-header Attribute modify "a=ice-.*" "a=label:main-audio"
!
voice class sip-profiles 299
rule 9 request ANY sip-header Via modify "SIP(.*) 10.10.10.10(.*)" "SIP\1 1.2.3.4\2"
rule 10 request OPTIONS sip-header From modify "<sip:10.10.10.10" "<sip:fqdn_here"
rule 20 request OPTIONS sip-header Contact modify "<sip:10.10.10.10" "<sip:fqdn_here"
rule 30 request OPTIONS sip-header User-Agent modify "(IOS.*)" "\1\x0D\x0AX-MS-SBC: Cisco UBE/ISR4451/\1"
rule 40 response ANY sdp-header Connection-Info modify "IN IP4 10.10.10.10" "IN IP4 1.2.3.4"
rule 50 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.10.10.10" "IN IP4 1.2.3.4"

Scott Leport · ‎03-02-2021

Hi Richard,

It looks good, but what I meant was are the profiles applied to the sip configuration? E.G

voice service voip

sip

sip profiles inbound

richard.priest · ‎03-02-2021

Ahh apologies

voice service voip
ip address trusted list
ipv4 x.x.x.x 255.255.0.0
ipv4 x.x.x.x
ipv4 x.x.x.x 255.255.255.0
ipv4 x.x.x.x 255.255.255.0
ipv4 x.x.x.x 255.255.255.255
ipv4 x.x.x.x 255.255.255.252
rtcp keepalive
address-hiding
mode border-element
allow-connections sip to sip
no supplementary-service sip refer
supplementary-service media-renegotiate
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
trace
sip
bind control source-interface GigabitEthernet0/0/3
bind media source-interface GigabitEthernet0/0/3
session refresh
header-passing
error-passthru
conn-reuse
pass-thru headers 290
sip-profiles inbound

Scott Leport · ‎03-02-2021

Hi Richard,

If you have followed the document as closely as you can, then it might be something else that's at play here.

Have you got the following allowances configured on your Firewall as per this Microsoft document? Review the section "Media Traffic: Port ranges" on down.

https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan

richard.priest · ‎03-02-2021

Thanks again Scott, I presume by media processor that document means the MTP in CISCO parlance?

In this instance there are no firewalls or any form of ACL / traffic filtering between the SBC / CUBE and the MTP.

As the call is connecting fine could it be a codec issue on the MTP? I've spanned the traffic from my CISCO handset to my laptop via Wireshark and can see the voice traffic being sent to/from the MTP. Looking at the MTP I can see the voice call is active.

THE CUBE has a DSP, is it worth configuring that as a transcoder to remove the MTP element? (though the MTP works fine for all the other SIP trunks we have!

Obviously what I can't really analyse easily is the TEAMS client

Scott Leport · ‎03-02-2021

Hi Richard,

No, I interpret the media processors as the component on MS Teams which handles the media for the calls.

Is your MTP on the same device as the CUBE or is it on a different device?

Apologies, maybe I am missing something, but would it not be better to run a packet capture either on the Firewall or the CUBE to troubleshoot the inbound call from CUBE to Teams?

richard.priest · ‎03-02-2021

I can see traffic entering / leaving the firewall from the CUBE fine

The MTP is a different device to the CUBE. I can try configuring the cube to do the transcoding though

I've run a packet capture on the MTP and can see IP packets entering & leaving as I'd expect. it was just a debug ip packet though, (with a relevant ACL applied). I'm not sure what other debug can be run to check?

I've not done the same on the CUBE, but as the call connects & I can see SIP messages working I'd have thought thus was OK?

Scott Leport · ‎03-03-2021

Hi Richard,

You could run a "debug sccp all" on your MTP, but to be honest, I am not sure that would even highlight a problem here.

If the call connects, it proves the signalling is good, but it does not necessarily prove RTP.

I am sure you've ruled this out, but figured I'd ask, have you got the IP routing in place towards the Teams /14 subnets I supplied in my earlier posts and is it going out the expected path?

richard.priest · ‎03-04-2021

Cheers Scott,

I've run a debug sccp all on the MTP, but being honest I can't make any sense of the output other than verifying the source / dest IP addresses.

the CUBE has indeed got routing to the TEAMS /14 subnets, I don't think the SIP trunk would be up if this were the case?

Cheers

Scott Leport · ‎03-04-2021

Well.....technically if you were routing to the Teams SIP signalling subnet (which I believe is 52.114.0.0/16, within the 52.112.0.0 /14 net), but not the media processor servers on 52.120.0.0/14 you could run into these issues. That's where the direct routing document isn't completely clear as it doesn't mention the 52.120.0.0 range.

If you have the 2x /14's routes added and they're going out the same path, that's probably not your issue.

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?

richard.priest · ‎03-04-2021

Yeah that's not that clear.

I just double/triple checked and the CUBE is deffo routing to 52.120.0.0/14, however the MTP will route to those addresses via a different egress point,

My understanding is that shouldnt matter though? the CUBE does all the 'talking' to TEAMS?

Once thing I find odd after you mentioning that 52.120.0.0/24 is the media processor servers, I see nothing on the firewall logs that the CUBE routes though when I make a call...

I see the 5061 SIP traffic setting up the call to a 52.114 range address

richard.priest · ‎03-04-2021

I've removed MTP requirements from the SIP trunk, no change in behaviour

Scott Leport · ‎03-04-2021

Hi Richard,

I would say that you want to ensure the 2x /14 subnets from CUBE are going out the same path. Would removing the MTP requirements have changed the path at all?

Would you be able to supply your CUBE config at all (removing any sensitive info of course) and if possible supply the following from the CUBE please:

debug ccsip messages

show voip rtp connections

show call active voice