Solved: Jabber MRA cannot make external calls - Page 2

cehr_itsupport · ‎11-06-2017

Hi,

Hoping someone can help with a Jabber MRA problem. This seems to be affecting the later Jabber release 1.8.x and I on IOS (TCT) and Android (BOT) plus Windows and Mac devices and I reckon it's codec related. The problem is we cannot dial any external landline or cell \ mobile numbers through MRA; this happens when the MRA device is connected to WiFi and 4G\cell. The Called party device rings once and then the call automatically disconnects. The call logs report "501 Not Implemented" and "Reason: Q.850;cause=65".

Call route is Jabber MRA device > Expressway-E > Expressway-C > CUCM > SIP Trunk to SIP provider (BT)

Windows CSF devices work fine through MRA using earlier Jabber v11.7.0.
Calls to internal numbers from any MRA device are OK (on Wifi and 4G).

CUCM is v11.5.1.13900-52
Expressway Edge and Core are vX8.10.1
Jabber on IOS and Android is latest v11.9.1

I've had a look at the call logs and I can see that the INVITE from the IOS \ Android devices includes an additional audio codec (number "111") compared to the CSF:

INVITE from Expressway to CUCM
==========================

v=0
o=tandberg 0 1 IN IP4 xxxxx
s=-
c=IN IP4 xxxxx
b=AS:1024
t=0 0
a=cisco-mari:v1
a=cisco-mari-rate
m=audio 55360 RTP/AVP 114 9 104 105 0 8 18 111 101
a=rtpmap:114 opus/48000/2
a=rtpmap:9 G722/8000
a=rtpmap:104 G7221/16000
a=fmtp:104 bitrate=32000
a=rtpmap:105 G7221/16000
a=fmtp:105 bitrate=24000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:111 x-ulpfecuc/8000
a=fmtp:111 max_esel=1420;m=8;max_n=32;FEC_ORDER=FEC_SRTP
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=extmap:14/sendrecv http://protocols.cisco.com/timestamp#100us
a=sendrecv
a=rtcp:55361 IN IP4 10.x.x.x

INVITE from CUCM to SIP Provider - includes the same 111 codec:
=================================================

v=0
o=CiscoSystemsCCM-SIP 4388142 1 IN IP4 xxxxx
s=SIP Call
c=IN IP4 xxxxx
b=TIAS:8000
b=AS:8
t=0 0
a=cisco-mari:v1
a=cisco-mari-rate
m=audio 55360 RTP/AVP 18 114 111 101
a=extmap:14/sendrecv http://protocols.cisco.com/timestamp#100us
a=rtpmap:114 opus/48000/2
a=rtpmap:111 X-ULPFECUC/8000
a=fmtp:111 max_esel=1420;m=8;max_n=32;FEC_ORDER=FEC_SRTP
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtcp:55361 IN IP4 10.x.x.x

OFFER from SIP Provider back to CUCM
=================================

We see the SIP Provider offering back the following. The "m=8;max_n=32;FEC_ORDER=FEC_SRTP 0" attribute seems completely out of place.

v=0
o=genband 322521088 1508711079 IN IP4 xxxxx
s=-
c=IN IP4 xxxxx
t=0 0
m=audio 47230 RTP/AVP 18
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=ptime:20
m=8;max_n=32;FEC_ORDER=FEC_SRTP 0
a=rtpmap:18 0 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Question then is is this an issue with the Jabber app, CUCM, Expressway or the SIP provider, or something else completely?

Thanks

Lee

cehr_itsupport · ‎11-08-2017

Thanks Slavik, really appreciate all your help. I’m going to try a few more things (e.g. see if the addline parameter will work) as it is odd that no changes are being made to the SDP content. If that doesn’t work then might have to get a TAC case opened. Lee

Slavik Bialik · ‎11-08-2017

If you solve it, please share the solution. It got me very interested as I work a lot with MRA and Jabber deployments.

Good luck mate!

cehr_itsupport · ‎11-08-2017

SUCCESS! Just got this working (need to do a bit more testing), but the script below seems to do what I need and this is the first time in weeks I've managed to call an external number from Jabber MRA. The script below has been applied on the SIP Trunk to our SIP provider, so not directly on the Expressway Trunk as I was doing.

Whilst the script works, I cannot for the life of me find the trace output in the SDL files. Any thoughts? Pretty sure all the right trace settings are on in Serviceability.

M={}
trace.enable()
function M.outbound_INVITE(msg)
local sdp = msg:getSdp()
if sdp
then
sdp = sdp:removeLine("a=rtpmap", "x-ulpfecuc")
sdp = sdp:removeLine("a=fmtp", "m=8;max_n=32;FEC_ORDER=FEC_SRTP")
trace.format("### Removed X-ULPFECUC Codec ###")
msg:setSdp(sdp)
end
end
return M

Thanks for the pointers - would never have resolved this without your help :-)

Lee

Slavik Bialik · ‎11-09-2017

Nice, glad to hear you've managed to get the script working!

But... I cannot see a big difference between this script and the previous one? What was the mistake?

And besides the script itself, can you now make MRA calls? Is it fixed because you've managed to remove this cursed codec?

cehr_itsupport · ‎11-09-2017

Hi Slavik,

I originally applied the script to the trunk between CUCM and Expressway which made no difference So had a change of plan and applied the script to the trunk to the SIP Provider and it worked first time. Time permitting I might investigate further why it didn’t work on Expressway trunk.

I suppose the way it’s working now is the ideal way - we only have problems with calls out via the ITSP so no reason to amend calls just between Expressway and internal devices.

Yes, all MRA devices can now make external calls :-)

I do have one outstanding issue - the trace.enable() and trace.format() commands in the script either aren’t writing to the SDL file or I’m not looking in the right place. Trace is enabled on the script option on the trunk and I’ve checked Serviceability where detailed logging is enabled on all CM nodes. Any thoughts?

thanks

Lee

Slavik Bialik · ‎11-09-2017

I'm wondering how MRA is working in your deployment if you have a SIP trunk configured from your CUCM towards the Expressway-C. Because it shouldn't work at all and it is not allowed. MRA can't work with a SIP trunk configured. Unless, you implemented a B2B calls through your Expressway to the outside, and you configured that the local port of this SIP trunk differs from 5060.
About the trace part, I'm not really sure as I never did a trace. I only know the following:

1. The trace should be enabled in your script itself.
2. The trace should be enabled on the SIP trunk.
3. Under Trace Configurations, in the Serviceability page, the " Enable SIP Stack Trace" must be checked and debug trace level should be set to "Detailed".
And in that case, I can only guess you should see the SIP messages and their changes in the SDL.

cehr_itsupport · ‎11-10-2017

Thanks Slavik,

The MRA deployment is as per the B2B design with Expressway-C and E deployments. The SIP Trunk connects the EXP-C to the CUCM and a separate trunk from CUCM to the SIP Provider.

Trace output is also working now - thanks - the "Enable SIP Stack Trace" option was not selected!

Thanks very much for your help!

Lee