cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1590
Views
0
Helpful
9
Replies

CUCME 7.1 1-way audio after 30 minutes

dsmith16
Level 1
Level 1

Hello!

On a 2801 running 12.4(24)T2 IOS, and CUCME 7.1, after a call has been up for 30 minutes (on the dot), we get 1-way audio (external party on the PSTN can hear us, we cannot hear them).  I've been trying the bug tool, but haven't found anything applicable so far. 

Any ideas/suggestions would be greatly appreciated!

Thank you,

Deb

9 Replies 9

Logan Gaffney
Level 1
Level 1

Is the connection to te PSTN a SIP trunk/PRI/FXO port?  Based on the problem is sounds like a SIP trunk.  If it is we would need to get the following debugs during the call:

debug ccsip message

Also indicate the calling/called numbers and attach a "show run".

Thanks!

***Please rate helpful posts

Thanks for the reply, Logan!

Yes, the problem is with calls through SIP.  I will send the info requested this evening (PDT).  I'm tied up in a class until then.

Cheerio,

Deb

Hi, Logan.

Sorry for the delay.

Attached are the two requested items: debug ccsip message, and output of show run.

Called number: 17079610885

Calling number: 17079691929

Thank you for any time/help that you may have!

Deb

Hi Deb,

I did not see any calls made to 17079610885 or 17079691929 in the debugs.  I did see registrations made by 17079691929 to the provider but that is it. 

Issue the following and try to get another set of logs after the 30 minutes:

conf t

service sequence

service timestamp debug datetime local msec


I am going out on a limb here without the debugs but the most likely cause is something in the SDP's of the REINVITE from the provider (or CME's interperatation of them).  Again, would need to see the call flow in its entirety.

Thanks!


Oops!  Sorry.  I'd been testing between a couple of different call pairs.

The one in the debug that I sent you is this:

Calling: 18664329903

Called: 17079616237

Regards,

Deb

Hi again, Logan.

Attached is the debug output with the additional services enabled.  I *assume* that this trace represents one-way audio, but in this case there was no one to speaking on the other end to confirm it.  However, it was the exact same call that has been reliably failing 100% of the time at the 30 minute point, and so I hope that it is useful.

Calling:  18664329903

Called:  17079616237

By the way, I've also confirmed that a call out our SIP trunk, and back in an FXO, does not seem to have this problem (not tested extensively, but after 3 times so far, there's been no failure). 

Regards,

Deb

Jason Polce
Level 4
Level 4

I ran into a similar problem where after exactly 30 minutes the call would drop on our CME router. It was a problem with the REINVITE between CME and our SIP provider just like Logan mentioned. Here is what we did to fix it, you may have some luck with this but might have to tweak it depending on what your provider is looking for:

voice class sip-profiles 100
request INVITE sip-header Allow-Header modify ", UPDATE" ""
request REINVITE sip-header Allow-Header modify ", UPDATE" ""
response 180 sip-header Allow-Header modify ", UPDATE" ""
response 200 sip-header Allow-Header modify ", UPDATE" ""

voice service voip
  sip-profiles 100

Hope that helps you.

- Jason

Thank you for sending the changes that worked for you, Jason. 

That sounds very promising for a fix for us as well.

I'll wait to hear back from Logan, and unless he has something very different to suggest,I'll expect to be trying your changes (or similar--may do some debugs with our provider first to see time/s req'd).

Thanks again for taking the time to respond!

Deb

Well, looks like I have a different problem. 

I tried adding your suggested config, Jason, but I still have the same problem.

Unless Logan has another idea, looks like I'll need to do some debugging with my SIP provider. 

What's particularly interesting is that the problem is not with all calls through SIP.  It seems to happen with many, but I can make a call out through SIP, and back in my CME router's FXO, and that call does not have the problem (at least, through several test calls). 

Thanks again for taking the time to help!

Deb