cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
1525
Views
0
Helpful
6
Replies
Alexey Smirnov
Enthusiast

3rd party SIP devices drop calls after 15 min.

Hello!

I have a CUCM with 2 3rd party SIP devices (Advanced) registered with it. The symptoms are: I can call from 1st device to 2nd and vise versa, but call drops after 15 minutes.

Devices are in different regions with Max Audio Bitrate of G.711, Maximum Session Bit Rate for Video and Immersive Calls 3072kbps.

They are also in different locations but with unlimited BW.

Here is their SIP dialog right before disconnect:

SIP Bye @13.21.21.482 to both endpoints from CUCM has Reason: Q.850;cause=47

Last reinvite to device 1 is in cucm-dev1.txt

Last 200OK from device1 is in dev1-cucm.txt

Last reinvite to device 2 is in cucm-dev2.txt

Last 200OK from device2 is in dev2-cucm.txt

SDL traces from CUCM show:

49866833.001 |13:21:21.480 |AppInfo  |!!ERROR!! -MediaManager-(905711)::handle_MediaConnectErrorInd, mCleanupPreallocatedMTP=0

49866833.002 |13:21:21.480 |AppInfo  |!!ERROR!! -MediaManager-(905711)::handle_MediaConnectErrorInd, send disconn to 1 MXs

49866833.003 |13:21:21.480 |AppInfo  |!!ERROR!! -MediaManager-(905711)::handleMediaConnectErrorInd, mediaConnectRequestMsg party video capable (1=1, 2=1), ConnecterrorInd party capable (1=1, 2=1)

(full sdl is in sdftrace.txt)

 

The question is why call attempt succeeded and call lasted 15 minutes?

Does CUCM uses MTP for this call (at least RTMT doesn't show error like Number of MediaResourceListExhausted events with MediaResourceType : 1)?

How does CUCM tolerate a call with different video profiles (but with same payload type) in each direction?

 

 

6 REPLIES 6
Wayne DeNardi
VIP Advisor

Check the firewalls between the two sites.  It's highly likely that one of them is closing the ports after a certain timeout, which is then causing your call to drop.

Note: Your question would be better placed in the TelePresence section of the forums where these devices are more actively discussed than in the Video Over IP section you've posted in - I'd suggest, if the above hasn't answered your query, that you move your discussion over there.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.

 

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.

Thank you for your suggestion, but there is no firewall between endpoints.

I forgot to mention that 1st device is Lifesize 220 (FW 2.2.1) and 2nd is Lifesize Icon 600 (FW 5.0.3).

I've made a call from 1st and 2nd to Cisco SX20 and they were ok.

I also found a bug CSCud38314 - but my version of CUCM is newer.

guess a full sip trace of the full call could be interesting.

especially the SDP and the reinvites.

The sdl trace shoes some media issues, so I could assume that this is the cause.

 

Did you check on the codec options, maybe it can help to disable uncommon ones.

A candidate for me would be h.264 high profile and uncommon audio codecs (opus, siren, ...)

Please remember to rate helpful responses and identify

moyo oyegunle
Beginner

Hello

It is more likely to be a firewall signalling time out issue as Wayne says.

Another thing you can try if your vc's support udp signalling make them use it. This might help if it's some sort of Timeout based on TCP.

This is very far off: but in the media section of your sdp there is :

c=IN IP4 0.0.0.0

From what I understand CUCM uses this to allow systems put themselves on hold but not all 3rd party equipment know how to handle it.Try registering the devices as 3rd party basic and see if it fixes that? 

Well, HOLD is definitely has something to do here. Right before dropping a call CUCM sends

a=inactive

in SDP to the first device.

Alexey Smirnov
Enthusiast

This problem appeared to be a bug in CCM

https://tools.cisco.com/quickview/bug/CSCuv06688

Content for Community-Ad

Spotlight Awards 2021