11-06-2017 01:53 PM - edited 03-17-2019 07:10 PM
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
Solved! Go to Solution.
11-08-2017 01:05 PM
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
11-08-2017 01:09 PM
11-08-2017 03:51 PM
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
11-09-2017 11:42 AM - edited 11-09-2017 11:42 AM
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?
11-09-2017 12:55 PM
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
11-09-2017 01:07 PM
11-10-2017 07:06 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide