Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
2331
Views
10
Helpful
6
Replies

CUCM Video drops over SIP Trunk: rtpmap invalid for videoPayloadType

kdotten36
Level 3
Level 3

‎09-01-2015 12:39 PM - edited ‎03-17-2019 04:10 AM

Any Video/SIP experts able to provide some advice?

Call flow is endpoint > CUCM (9.1.2) > SIP > CUBE (15.4(2)T1) > SIP > ITSP

I'm getting dropped video on calls made through the CUBE after an intermittent time between 20 and 120 minutes.  When the video drops, the audio remains active until the endpoint disconnects and dials back.  I've tried two different endpoints, a c40 and a DX650.

The CUCM SDLs show the following errors at every point the call disconnects.

getVideoCodecFromSDP:  rtpmap invalid for videoPayloadType=100
getVideoCodecFromSDP:  Error! cannot convert pt=100
getVideomLine:  videoPayloadType=100
 
The errant payload type the first few times was 97, which by default is fax-relay on CUBE, so I manually changed 97 to h.264 on the dial-peer (we don't use faxing) and on my next attempt I got 100 as seen above, which is cisco default for NSE.  I don't want to keep changing these values for fear of breaking something else, and I'm trying to avoid making global changes that could affect voice, so I'm hoping there's better advice out there.  My Google skills seem lacking for this error.
 
Below are the voice, sip and dial-peer configs.  I have CUCM SDL and CUBE ccsip messages debugs but the error above seems to be the only commonality among video loss.
 
VOICE SERVICE CONFIG 
 
voice service voip
 ip address trusted list
  ipv4 #
 mode border-element
 allow-connections sip to sip
 no supplementary-service sip moved-temporarily
 no supplementary-service sip refer
 supplementary-service media-renegotiate
 signaling forward unconditional
 fax protocol none
 modem passthrough nse codec g711ulaw
 sip
  rel1xx disable
  min-se 180 session-expires 180
  session refresh
  header-passing
  registrar server expires max 600 min 60
  early-offer forced
  midcall-signaling passthru
  sip-profiles 101
!
voice class codec 1
 codec preference 1 g729br8
 codec preference 2 g711ulaw
 codec preference 3 g729r8
!
!
voice class sip-profiles 101
 request INVITE sip-header Allow-Header remove
 response 200 sip-header Allow-Header remove
 response 180 sip-header Allow-Header remove
 response 183 sip-header Allow-Header remove
 
 
DIALPEER FOR VIDEO CALLS
 
dial-peer voice 1900 voip
 description OUTBOUND video
 destination-pattern 1900
 media flow-around
 rtp payload-type cisco-codec-fax-ack 107
 rtp payload-type cisco-codec-video-h264 97
 session protocol sipv2
 session target ipv4:#
 session transport tcp
 voice-class codec 1 offer-all
 voice-class sip pass-thru content sdp
 no vad
!
!
sip-ua
 
 
Labels:
0 Helpful
6 Replies 6

avinsrid89
Level 1
Level 1

‎09-01-2015 01:50 PM

This is a SIP signalling issue from the symptoms.

Can you share the CUCM SDL traces and CUBE debugs for a sample call?

Also, the error you pasted is not relevant to the problem.

~Avinash

0 Helpful

kdotten36
Level 3
Level 3
In response to avinsrid89

‎09-01-2015 02:05 PM

So much for my investigative skills.

Attached are the traces and debugs.

The call came from 7182 outbound to 1900

The video dropped at 10:05am.  It had been connected for approximately an hour.  Thanks for the assist.

Preview file
7307 KB
sdl_0.zip
0 Helpful

avinsrid89
Level 1
Level 1
In response to kdotten36

‎09-01-2015 02:41 PM

Exactly 1 hour after the video call, at 10:04 we are seeing a RE INVITE from CUCM to CUBE:

23749547.001 |10:04:50.525 |AppInfo  |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.1.100.9 on port 5060 index 2578 
[893795,NET]
INVITE sip:1900@10.1.100.9:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.1.100.5:5060;branch=z9hG4bK18591311623b6
From: "Kevin Otten" <sip:7182@10.1.100.5>;tag=282973~d7209104-12ad-41f7-8caa-6cd25334c8e6-21017782
To: <sip:1900@10.1.254.10>;tag=837DD29C-16EE
Date: Tue, 01 Sep 2015 14:04:50 GMT
Call-ID: 2fe5a00-5e51a26d-ed07-564010a@10.1.100.5
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CP-DX650/10.2.4
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 116 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  1800;refresher=uac
P-Asserted-Identity: "Kevin Otten" <sip:7182@10.1.100.5>
Remote-Party-ID: "Kevin Otten" <sip:7182@10.1.100.5>;party=calling;screen=yes;privacy=off
Contact: <sip:67182e91-e4e1-b379-e416-d605e99e301e@10.1.100.5:5060;transport=tcp>;+u.sip!devicename.ccm.cisco.com="SEP00082FB6052A";bfcp
Content-Type: application/sdp
Content-Length: 2193

v=0
o=CiscoSystemsCCM-SIP 282973 1 IN IP4 10.1.100.5
s=SIP Call
b=TIAS:4032000
b=AS:4032
t=0 0
m=audio 32220 RTP/AVP 108 9 124 0 8 116 18 101
c=IN IP4 10.1.101.21
b=TIAS:64000
a=rtpmap:108 MP4A-LATM/90000
a=fmtp:108 bitrate=64000;profile-level-id=24;object=23
a=rtpmap:9 G722/8000
a=ptime:20
a=rtpmap:124 iSAC/16000
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:116 iLBC/8000
a=ptime:20
a=maxptime:20
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 18252 RTP/AVP 100 126 97
c=IN IP4 10.1.101.21
b=TIAS:4000000
a=label:11
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=640016;packetization-mode=1;max-mbps=267300;max-fs=8910;max-rcmd-nalu-size=256000;level-asymmetry-allowed=1;max-fps=6000
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=428016;packetization-mode=1;max-mbps=267300;max-fs=8910;max-rcmd-nalu-size=256000;level-asymmetry-allowed=1;max-fps=6000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=428016;packetization-mode=0;max-mbps=267300;max-fs=8910;max-rcmd-nalu-size=256000;level-asymmetry-allowed=1;max-fps=6000
a=imageattr:* recv [x=1024,y=600,q=0.60] [x=1280,y=720,q=0.50]
a=content:main
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
m=video 25500 RTP/AVP 100 126 97
c=IN IP4 10.1.101.21
b=TIAS:4000000
a=label:12
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=640016;packetization-mode=1;max-mbps=267300;max-fs=8910;max-rcmd-nalu-size=256000;level-asymmetry-allowed=1;max-fps=6000
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=428016;packetization-mode=1;max-mbps=267300;max-fs=8910;max-rcmd-nalu-size=256000;level-asymmetry-allowed=1;max-fps=6000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=428016;packetization-mode=0;max-mbps=267300;max-fs=8910;max-rcmd-nalu-size=256000;level-asymmetry-allowed=1;max-fps=6000
a=imageattr:* recv [x=1024,y=600,q=0.60] [x=1280,y=720,q=0.50]
a=content:slides
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
m=application 23468 UDP/BFCP *
c=IN IP4 10.1.101.21
a=floorctrl:s-only c-only
a=floorid:3 mstrm:12
a=confid:1
a=userid:760

 

In this re invite, we can see that CUCM sends the video port as well as codecs to CUBE end.

But CUBE responds with video port as 0 implying this can cause a one way video possibly.

 

OK from CUBE:

23749553.002 |10:04:50.731 |AppInfo  |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.1.100.9 on port 5060 index 2578 with 1220 bytes:
[893797,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.1.100.5:5060;branch=z9hG4bK18591311623b6
From: "Kevin Otten" <sip:7182@10.1.100.5>;tag=282973~d7209104-12ad-41f7-8caa-6cd25334c8e6-21017782
To: <sip:1900@10.1.254.10>;tag=837DD29C-16EE
Date: Tue, 01 Sep 2015 14:04:50 GMT
Call-ID: 2fe5a00-5e51a26d-ed07-564010a@10.1.100.5
CSeq: 116 INVITE
Allow-Events: telephone-event
Remote-Party-ID: <sip:1900@10.1.100.9>;party=called;screen=no;privacy=off
Contact: <sip:1900@10.1.100.9:5060;transport=tcp>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.4.2.T1
Session-Expires:  1800;refresher=uac
Require: timer
Supported: timer
Content-Type: application/sdp
Content-Length: 525

v=0
o=CiscoSystemsSIP-GW-UserAgent 9690 702 IN IP4 10.1.100.9
s=SIP Call
c=IN IP4 10.1.100.9
t=0 0
m=audio 24954 RTP/AVP 0 101
c=IN IP4 10.1.100.9
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
m=video 0 RTP/AVP 100
c=IN IP4 10.1.100.9
a=label:11
a=content:main
m=video 0 RTP/AVP 100
c=IN IP4 10.1.100.9
a=label:12
a=content:slides
m=application 25016 UDP/BFCP *
c=IN IP4 10.1.100.9
a=connection:new
a=floorctrl:s-only
a=confid:1
a=userid:760
a=floorid:3 mstrm:12

This possible means that CUBE is getting some wrong information from ISP side.

 

So the ISP i.e. possible BlueJeans here is sending the right video port but with codec value 0. Hence CUBE probably assumes that there is no more video and hence shuts the video port by sending 0 on the port side as seen above. Here is the OK from BLUEJEANS for corresponding RE INVITE.

 

2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742850: Via: SIP/2.0/TCP 10.1.100.9:5060;rport=61495;received=209.124.163.221;branch=z9hG4bK18CF51977
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742851: Call-ID: DA31CBAE-4FE011E5-BC4DC3B8-3B3F139A@10.1.100.9
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742852: From: "Kevin Otten" <sip:7182@10.1.100.9>;tag=837DCE58-1BC5
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742853: To: <sip:1900@199.48.152.155>;tag=614005bc-ff34-4295-acbf-657f7c4a07ec
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742854: CSeq: 116 INVITE
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742855: Contact: "BlueJeans" <sip:1900@199.48.152.155:5060;transport=tcp>
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742856: Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, INFO, OPTIONS
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742857: Supported: 100rel
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742858: Content-Type: appl
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742859: ication/sdp
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742860: Content-Length:   901
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742861:
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742862: v=0
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742863: o=BlueJeans 3650101486 3650101492 IN IP4 199.48.152.155
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742864: s=-
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742865: c=IN IP4 199.48.154.170
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742866: t=0 0
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742867: m=audio 5842 RTP/AVP 0
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742868: a=rtcp:5843
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742869: a=rtpmap:0 PCMU/8000
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742870: a=sendrecv
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742871: m=video 5844 RTP/AVP 0
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742872: b=TIAS:1472000
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742873: a=rtcp:5845
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742874: a=rtpmap:0 H264/90000
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742875: a=fmtp:0 profile-level-id=42801f;max-mbps=108500;max-fs=3600
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742876: a=rtcp-fb:* nack pli
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742877: a=rtcp-fb:0 nack
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742878: a=rtcp-fb:* ccm fir
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742879: a=rtcp-fb:* nack sli
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742880: a=rtcp-fb:* ack rpsi
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742881: a=rtcp-fb:* ccm tmmbr
2015-09-01 10:04:50 Local7.Debug 10.1.100.9 10742882: a=content:main
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742883: a=label:11
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742884: a=sendrecv
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742885:
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742886: m=video 5846 RTP/AVP 0
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742887: b=TIAS:1024000
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742888: a=rtcp:5847
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742889: a=rtpmap:0 H264/90000
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742890: a=fmtp:0 profile-level-id=42801f;max-mbps=108500;max-fs=3600
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742891: a=rtcp-fb:* nack pli
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742892: a=rtcp-fb:0 nack
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742893: a=rtcp-fb:* ccm fir
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742894: a=rtcp-fb:* nack sli
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742895: a=rtcp-fb:* ack rpsi
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742896: a=rtcp-fb:* ccm tmmbr
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742897: a=content:slides
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742898: a=label:12
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742899: a=sendrecv
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742900: m=application 5666 UDP/BFCP *
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742901: a=floorctrl:s-only
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742902: a=floorid:3 mstrm:12
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742903: a=confid:1
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742904: a=userid:760
2015-09-01 10:04:51 Local7.Debug 10.1.100.9 10742905: a=connection:new

 

1) Also, the CUBE debugs are not very clear as they seem to be taken from a logging server. Is it possible to get debug ccsip messages for a sample call?

2) This issue however points to BlueJeans.

3) Also, are we doing any hold/resume during the test calls?

~Avinash

kdotten36
Level 3
Level 3
In response to avinsrid89

‎09-03-2015 09:56 AM

Thanks for the info and apologies for the delay in providing a new call trace.

1. You are correct that debug was from a syslog server.  I made a new sample and pulled it straight from the buffer, attached, as well as new SDL logs with the same m=video 0 issue as you mentioned.

2. I'll open a case with our telecom provider and BlueJeans to see if they have any input.  

3. No holding or resuming, these are test sessions from a browser to a phone on my desk that I push aside and wait to fail for log collection.

The video dropped from the call in the attached traces at 12:38pm.

Let me know if it helps or if I just need to take it up with the other end.  I appreciate it.

sdl001_100_000159.zip
putty_1.zip
0 Helpful

avinsrid89
Level 1
Level 1
In response to kdotten36

‎09-03-2015 10:03 AM

Yes this is an issue from Blue Jeans,

CUBE sends the below message with 0 port to CUCM:

599075: Sep  3 12:38:21.923: //89910/CA00E9800000/SIP/Msg/ccsipDisplayMsg:
Sent: 
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.1.100.5:5060;branch=z9hG4bK1d4785c5c6c75
From: "Kevin Otten" <sip:7182@10.1.100.5>;tag=316830~d7209104-12ad-41f7-8caa-6cd25334c8e6-21034075
To: <sip:1900@10.1.254.10>;tag=8E571D5C-29B
Date: Thu, 03 Sep 2015 16:38:21 GMT
Call-ID: ca00e980-5e816968-10f0a-564010a@10.1.100.5
CSeq: 116 INVITE
Allow-Events: telephone-event
Remote-Party-ID: <sip:1900@10.1.100.9>;party=called;screen=no;privacy=off
Contact: <sip:1900@10.1.100.9:5060;transport=tcp>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.4.2.T1
Session-Expires:  1800;refresher=uac
Require: timer
Supported: timer
Content-Type: application/sdp
Content-Length: 525

v=0
o=CiscoSystemsSIP-GW-UserAgent 6674 665 IN IP4 10.1.100.9
s=SIP Call
c=IN IP4 10.1.100.9
t=0 0
m=audio 20112 RTP/AVP 0 101
c=IN IP4 10.1.100.9
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
m=video 0 RTP/AVP 100
c=IN IP4 10.1.100.9
a=label:11
a=content:main
m=video 0 RTP/AVP 100
c=IN IP4 10.1.100.9
a=label:12
a=content:slides
m=application 20098 UDP/BFCP *
c=IN IP4 10.1.100.9
a=connection:new
a=floorctrl:s-only
a=confid:1
a=userid:960
a=floorid:3 mstrm:12

 

This is sent because Blue Jeans sent an OK to CUBE with 0 as video Codec :

599073: Sep  3 12:38:21.915: //89914/CA00E9800000/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.1.100.9:5060;rport=53619;received=38.124.154.65;branch=z9hG4bK1CF66704
Call-ID: A1230BCE-518811E5-9019C3B8-3B3F139A@10.1.100.9
From: "Kevin Otten" <sip:7182@10.1.100.9>;tag=8E5718B0-DDC
To: <sip:1900@199.48.152.155>;tag=ac3053a6-bf6e-45a9-b1af-40741091bcc2
CSeq: 116 INVITE
Contact: "BlueJeans" <sip:1900@199.48.152.155:5060;transport=tcp>
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, INFO, OPTIONS
Supported: 100rel
Content-Type: application/sdp
Content-Length:   901

v=0
o=BlueJeans 3650283497 3650283503 IN IP4 199.48.152.155
s=-
c=IN IP4 199.48.154.163
t=0 0
m=audio 5100 RTP/AVP 0
a=rtcp:5101
a=rtpmap:0 PCMU/8000
a=sendrecv
m=video 5104 RTP/AVP 0
b=TIAS:1472000
a=rtcp:5105
a=rtpmap:0 H264/90000
a=fmtp:0 profile-level-id=42801f;max-mbps=108500;max-fs=3600
a=rtcp-fb:* nack pli
a=rtcp-fb:0 nack
a=rtcp-fb:* ccm fir
a=rtcp-fb:* nack sli
a=rtcp-fb:* ack rpsi
a=rtcp-fb:* ccm tmmbr
a=content:main
a=label:11
a=sendrecv
m=video 5108 RTP/AVP 0
b=TIAS:1024000
a=rtcp:5109
a=rtpmap:0 H264/90000
a=fmtp:0 profile-level-id=42801f;max-mbps=108500;max-fs=3600
a=rtcp-fb:* nack pli
a=rtcp-fb:0 nack
a=rtcp-fb:* ccm fir
a=rtcp-fb:* nack sli
a=rtcp-fb:* ack rpsi
a=rtcp-fb:* ccm tmmbr
a=content:slides
a=label:12
a=sendrecv
m=application 5546 UDP/BFCP *
a=floorctrl:s-only
a=floorid:3 mstrm:12
a=confid:1
a=userid:960
a=connection:new

Please rate if you found this post useful!

~Avinash

 

kdotten36
Level 3
Level 3
In response to avinsrid89

‎09-03-2015 10:26 AM

Ok, thanks for checking.  I'll open tickets with BlueJeans and the ITSP, TW/Level 3, then post findings or solution.

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents