Outgoing Jabber Calls to ISP are getting failed due to Video Codec

[bhushansharma]

Hi All,

We are getting outbound international calls failed with dest cause code 127, when made via Jabber (12.7) while deskphone (majorly 7965) and CIPC calls are getting matured properly.

Call Flow: Jabber > CUCM > SIP Trunk > ISP (SBC)

We checked this with vendor and they suspect this may be due to H.264 codecs being sent via Jabber for calls.

Follwing is the SIP INVITE from Jabber:

INVITE sip:9001918802XXXXX@APC-OGIPTCCM902.ad.moodys.net;user=phone SIP/2.0
Via: SIP/2.0/TCP 10.12.241.62:58468;branch=z9hG4bK0000615b
From: "XYZ" <sip:2607@APC-OGIPTCCM902.ad.moodys.net>;tag=0205857feb80008400006639-000033a9
To: <sip:9001918802XXXXX@APC-OGIPTCCM902.ad.moodys.net>
Call-ID: 0205857f-eb800019-0000239a-0000124b@10.12.241.62
Max-Forwards: 70
Session-ID: 00004a4f00105000a0000205857feb80;remote=00000000000000000000000000000000
Date: Wed, 03 Jun 2020 08:55:38 GMT
CSeq: 101 INVITE
User-Agent: Cisco-CSF
Contact: <sip:66024460-b3d9-cd3c-428a-d7c845016c03@10.12.241.62:58468;transport=tcp>;+u.sip!devicename.ccm.cisco.com="CSFFraginaA";video;bfcp
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "XYZ" <sip:2607@APC-OGIPTCCM902.ad.moodys.net>;party=calling;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1
Allow-Events: kpml,dialog
Recv-Info: conference
Recv-Info: x-cisco-conference
Content-Length: 2534
Content-Type: application/sdp
Content-Disposition: session;handling=optional

v=0
o=Cisco-SIPUA 13008 0 IN IP4 10.12.241.62
s=SIP Call
b=AS:4000
t=0 0
a=cisco-mari:v1
a=cisco-mari-rate
m=audio 20686 RTP/AVP 114 9 104 105 0 8 18 111 101
c=IN IP4 10.12.241.62
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=extmap:14/sendrecv http://protocols.cisco.com/timestamp#100us
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-16
a=sendrecv
m=video 26128 RTP/AVP 126 97 111
c=IN IP4 10.12.241.62
b=TIAS:4000000
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=42801F;packetization-mode=1;level-asymmetry-allowed=1;max-mbps=244800;max-fs=8161;max-rcmd-nalu-size=32000
a=imageattr:126 recv [x=[32:1:1920],y=[18:1:1080],par=1.7778,q=1.00]
a=content:main
a=label:11
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801F;packetization-mode=0;level-asymmetry-allowed=1;max-mbps=244800;max-fs=8161
a=imageattr:97 recv [x=[32:1:1920],y=[18:1:1080],par=1.7778,q=1.00]
a=rtpmap:111 x-ulpfecuc/8000
a=extmap:14/sendrecv http://protocols.cisco.com/timestamp#100us
a=fmtp:111 max_esel=1420;m=8;max_n=32;FEC_ORDER=FEC_SRTP
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=rtcp-fb:* nack pli
a=recvonly
m=video 26020 RTP/AVP 126 97 111
c=IN IP4 10.12.241.62
b=TIAS:4000000
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=42801F;packetization-mode=1;level-asymmetry-allowed=1;max-mbps=244800;max-fs=8161;max-rcmd-nalu-size=32000
a=content:slides
a=label:12
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801F;packetization-mode=0;level-asymmetry-allowed=1;max-mbps=244800;max-fs=8161
a=rtpmap:111 x-ulpfecuc/8000
a=extmap:14/sendrecv http://protocols.cisco.com/timestamp#100us
a=fmtp:111 max_esel=1420;m=8;max_n=32;FEC_ORDER=FEC_SRTP
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=rtcp-fb:* nack pli
a=sendrecv
m=application 5620 UDP/BFCP *
c=IN IP4 10.12.241.62
a=floorctrl:c-s
a=confid:7
a=floorid:2 mstrm:12
a=userid:7
a=setup:actpass
a=connection:new
a=sendrecv
m=application 35282 RTP/AVP 125
c=IN IP4 10.12.241.62
a=rtpmap:125 H224/4800
a=rtcp:35283
a=sendrecv
m=application 58392 UDP/UDT/IX *
c=IN IP4 10.12.241.62
a=ixmap:11 xccp
a=setup:actpass
a=fingerprint:sha-256 EF:81:4F:8F:58:01:8D:32:26:97:20:A5:9F:35:06:F6:E1:64:22:44:B8:63:6B:B7:39:61:DD:CA:06:4D:B8:9A
a=sendrecv

Can someone please suggest

[Roger Kallberg]

Have a look at this document for how to suppress video. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-audio-forced.html

[bhushansharma]

Thanks for the help @Roger Kallberg , but we are sending calls directly to Vendor via SIP trunk( their equipment is on our site). Thus the last endpoint we manage in the flow is CUCM. Is there any way we can stop sending calls with video codecs. ( Maybe any restrictions on SIP trunk?? ) In Enterprise parameters, we have already enabled the 'Never Start Call with Video' for Cisco Jabber.

[Roger Kallberg · Accepted solution]

That's a very bad type of setup as you have no possibility for security as there is no demarcation point between you and the provider, plus that there is no point in the path where you can modify then call as you would be able to with a SBC (Cube). I'd seriously recommend you to revisit this design to put a SBC in-between your CUCM and the service provider.

[bhushansharma]

Agreed, I was talking about from Voice perspective, we do have MPLS network and firewalls in place between CUCM and Vendor SBC.

Appreciate your help @Roger Kallberg