Callers can't be heard unless they are put onhold then offhold

[missmibble]

Hi,

Recently upgraded to CCM9 but this problem existed since v7 (was hoping it would just go away).

Answered incoming calls have to be put on hold due to one way audio (outbound from the consultant to customer, consultant cannot hear the customer). Once call is retrieved there is two way audio, both parties can hear eachother.

CCM logs show call state changes, hold, call retrieved etc but nothing odd. It doesn't happen everytime but it definitely happens thanks to call recording proof.

Anyone seen this issue before?

[Jay Schulze]

Could you post the call flow please.

I ran into a very similar issue which turned out to be a defect and that was actually the work around to put them on hold and take them off. Than RTP was heard. If you are using a SIP trunk try 'checking the 'Require SDP Inactive Exchange for Mid-Call Media Change' on the SIP profile of the SIP trunk. Here is a little info about it, but just a shot in the dark without knowing the call flow. Just FYI when posting in issue always rule number would be to give the call flow so components will be known.

====================================================================================

If the box is checked, during mid-call codec or connection updates Cisco Unified Communications Manager sends an INVITE a=inactive SDP message to the endpoint to break the media exchange. This is required if an endpoint is not capable of reacting to changes in the codec or connection information without disconnecting the media. This applies only to audio and video streams within SIP-SIP calls.

Note	For early offer enabled SIP   trunks, this parameter will be overridden by the Send send-receive SDP in   mid-call INVITE parameter.

If the box is unchecked, Cisco Unified Communications Manager passes the mid-call SDP to the peer leg without sending a prior Inactive SDP to break the media exchange. This is the default behavior.

THX

J

[missmibble]

Morning,

Thanks for the reply :-)

Incoming calls are sent to CUSP (v8.5.4) and then to either CVP (v9) /ICM or CCM (v9.1.1) (general users). In this instance CVP (over the SIP trunk). A privacy message is played by CVP then the call is sent to an agent.

In CCM 9 the checkbox you reference isn't there so perhaps something has changed in the new version? I have an example so will put together the SIP messages to see if they fit what you have highlighted.

Thanks so much for giving me some direction :-)

[Jay Schulze]

Hello.

Sure I'd have to look back at the traces to be sure. But I'm almost certain that is the exact same thing I saw. This was on CUCM 9.1.1 as well. So the checkbox is defiently there. I would try see if that works it looks very similar. If not we can take a look at the SIP messages.

[missmibble]

Further to this, I found the relevant SIP msgs. Below is the Invite with the SDP info. With a media attribute a: inactive specified I expect this is what is causing the issue? I do have all the SIP msgs if you want them.

INVITE sip:0754295089@10.x.x.x:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.x.x.x:5060;branch=z9hG4bK2ccafb5acea754
From: <87500>;tag=1823925~0658a776-810b-400c-96b5-601229dbfb2a-37808247
To: "_" <0754295089>;tag=dsf3dd51fa
Date: Mon, 30 Dec 2013 00:35:35 GMT
Call-ID: C59A95B9702011E3A14EC08C60413880-138836371450673068@10.x.x.x
Supported: timer,resource-priority,replaces
Min-SE:  1800
Cisco-Guid: 3315242425-1881149923-2706292876-1614887040
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 102 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  1800;refresher=uac
P-Asserted-Identity: <87500>
Remote-Party-ID: <87500>;party=calling;screen=yes;privacy=off
Contact: <87500>
Content-Type: application/sdp
Content-Length: 246

v=0
o=CiscoSystemsCCM-SIP 1823925 3 IN IP4 10.x.x.x

s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=AS:64
t=0 0
m=audio 24612 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

To prevent Cisco Unified Communications Manager from sending an INVITE a=inactive SDP message during call hold or media break during supplementary services, edit the appropriate SIP profile, and check the Send send-receive SDP in mid-call INVITE check box.

Note This check box applies only to early offer enabled SIP trunks and has no impact on SIP line calls.

When you enable Send send-receive SDP in mid-call INVITE for an early offer SIP trunk in tandem mode, Cisco Unified Communications Manager inserts MTP to provide sendrecv SDP when a SIP device sends offer SDP with a=inactive or sendonly or recvonly in audio media line. In tandem mode, Cisco Unified Communications Manager depends on the SIP devices to initiate reestablishment of media path by sending either a delayed offer INVITE or mid-call INVITE with send-recv SDP.

When you enable both Send send-receive SDP in mid-call INVITE and Require SDP Inactive Exchange for Mid-Call Media Change on the same SIP profile, the Send send-receive SDP in mid-call INVITE setting overrides the Require SDP Inactive Exchange for Mid-Call Media Change setting, soCisco Unified Communications Manager does not send an INVITE with a=inactive SDP in mid-call codec updates. For SIP line side calls, the Require SDP Inactive Exchange for Mid-Call Media Change check box applies when enabled.

Note To prevent the SDP mode from being set to inactive in a multiple-hold scenario, set the Duplex Streaming Enabled clusterwide service parameter (System > Service Parameters) to True.