One-way audio after call is put on hold

[unwell_11]

Hi All,

Previously, we are using CUCM 9.1, H323 gateway, and ISDN for inbound and outbound calls without any issues.

Last night, we tried to use SIP for outbound calls to one of our local SIP providers. Everything seems to be working fine, but when testing the features, we encountered an issue with putting calls on hold.

Our set-up was:

CUCM --> sipv2 --> CUBE --> sipv2 --> ITSP

What happened is that if I make a call out from an SCCP phone (8941) to an external number, and then place that call on hold, the other party can hear music on hold fine. When I retrieve the call, they can hear me, but I cannot hear them.

I have these settings enabled on the SIP Profile.

- Early Offer support for voice and video calls (insert MTP if needed)

- Send send-receive SDP in mid-call INVITE

Looking at the CUBE SIP messages, here is a summary of what I saw:

- After I put the call on hold, i see re-INVITE from CUCM sent to CUBE with NO SDP (which is then forwarded to the ITSP).

- ITSP then responds with a 200OK with SDP that has a=sendrecv attribute which is received by CUBE

- CUBE then sends a 200 OK to CUCM with SDP, but without the a=sendrecv attribute.

- CUCM sends an ACK with a=sendonly to CUBE (which is then passed on to the ITSP). I believe this is fine, since at this stage the person on the other line could now hear MOH.

When I resume the call:

- another re-invite is sent with no SDP from CUCM to CUBE (which is forwarded on to the ITSP)

- ITSP sends to CUBE a 200 OK with SDP but, has a=recvonly attribute in it. This is in turn forwarded to CUCM, and CUCM responds with a=sendonly on its SDP.

I assumed that if you have Send send-receive SDP in mid-call INVITE ticked, it would do as it says - send an SDP during mid-call INVITEs. But based on the logs it's not doing what it's supposed to?

I tried ticking on "Media Termination Point Required" and this fixed the issue. However, reading some other posts here in the community, this is not the ideal fix.

If I could send a mid call INVITE with SDP, which will have the correct sendrecv attribute, it might probably fix the issue. But I can't seem to find any information to force Early Offer for mid-call invites?

Any assistance would be much appreciated. Thanks in advanced for the community's assistance!

[testeven · Accepted solution]

Hi, 

Can you try the following?

On CUCM go to System--- Service Parameters and look for "Duplex Streaming Enabled" set this to TRUE and restart the CCM service. Refer to: 

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_1_1/ccmsys/CUCM_BK_C5565591_00_cucm-system-guide-91/CUCM_BK_C5565591_00_cucm-system-guide-91_chapter_0101010.html

Regards, 

Tere.

[unwell_11]

Thanks, Tere! I'll read through the document you provided and make the change. I'll keep you posted if this fixes the issue. Thanks again!

[Nishant Savalia]

Hi ,

Could you please paste what was that service parameter that has been modified by TAC team for this resolution.

[Ayodeji Okanlawon]

On CUCM go to System--- Service Parameters and look for "Duplex Streaming Enabled" set this to TRUE and restart the CCM service

[Nishant Savalia]

Thank you Ayodeji,

But i have one doubt in Re-Invite message.

• If during first Invite message , SDP is sent then why in Re-Invite message, SDP is not sent?
•  

• When I resume the call:

  - another re-invite is sent with no SDP from CUCM to CUBE (which is forwarded on to the ITSP)

  - ITSP sends to CUBE a 200 OK with SDP but, has a=recvonly attribute in it. This is in turn forwarded to CUCM, and CUCM responds with a=sendonly on its SDP.

Then in this case it is ITSP who is sending a=recvonly in SDP then how that service parameter will affect and solve this issue?

Your explaination will be highly appreciated.

Regards,

Nishant Savalia

[Ayodeji Okanlawon]

Nishant,

This is how the process of call hold works..

1. CUCM sends invite (re-invite) with an inactive SDP (a=inactive) to indicate a break in media path

2. CUCM sends a Delayed offer to insert MOH or to resume Media stream

NB: CUCM expects a sendrecv offer with SDP to the DO. (NB:if cucm gets an inactive offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path remains in an inactive state and causes calls to dropcall will drop),CUCM sends an ACK with send only to the 200 OK

When you enable the feature send send-receive in midcall INVITE under sip profile, cucm does not send a=inactive in step 1 above rather it sends a send-receive

CUCM has to send SDP in the first re-INVITE. This is th eonly way for the other party to know that there is a break in media..It is possible that you are not looking at the first re-INVITE

You haven't mentioned what your issue is though and I dont know how that parameter will help.

[Nishant Savalia]

Thank you for your response.

Actually i don't have any issue but was just going through some post and in between i found this one so just digged into it.

I am just curious to know that how service parameter "Duplex Streaming Enabled" set this to TRUE and restart the CCM service, will help and inform CUCM to send a=sendrecv to reestablish media.

One more thing i would like to know is which parameter in Re-Invite message will help to resume the call (as this Re-Invite will be delayed offer)?

[Ayodeji Okanlawon]

That parameter as far as I know is used for MOH. It should affect how cucm sends its SDP. I dont know why this was used here..

To asnwer your second question,

Normally when a call is on hold you get something like this:

v=0
o=CiscoSystemsCCM-SIP 919861 2 IN IP4 10.10.30.14
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 30120 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

The connection parameter shows 0.0.0.0, When the call is taking off hold you, the connection parameter should indicate the ip address where media is sent to. So it will have a real value. ( This is usual sent in the ACK.) cucm still sends a DO in the re-INVITE and the far end sends a 200 Ok with SDP. CUCM then sends ACK with SDP

This is how the whole call hold/transfer/call resume works

1. CUCM sends invite (re-invite) with an inactive SDP (a=inactive) to indicate a break in media path

2. CUCM sends a Delayed offer to insert MOH or to resume Media stream

NB: CUCM expects a sendrecv offer with SDP to the DO. (NB:if cucm gets an inactive offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path remains in an inactive state and causes calls to dropcall will drop),CUCM sends an ACK with sendonly to the 200 OK

3.CUCM establishes newcall leg with the intended transfered destination..Once this call is connected

4.CUCM receives a new Transfer instruction from the transferring phone to connect the held party

5. Next CUCM sends a re-invite with an inactive SDP to indicate a break in media path to MOH (in attempt to complete transfer)

6.Next CUCM sends an inactive SDP to indicate a break in media path between transfering party & transfered party to remove Xferring party from call

7. Next CUCM sends a DO re-invite to connect the transfered party. The far end then sends 200 OK with the required SDP to connect the call

[Nishant Savalia]

Once again thank you for explaination.

[Jon Clark1]

Hello Deji,

Deji can you answer what setting for an ip phone (CSF in this case) on prem forces a=reconly in the initial SDP to cucm for an outgoing call?

All the other m lines (including other video m lines) all have a=sendrec but not this one m line. It's causing the other side to respond with all a=inactive's which gives no audio.

Thanks!

m=video 29804 RTP/AVP 126 97 111
c=IN IP4 10.41.72.98
b=TIAS:4000000
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=42E01F;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=42E01F;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

[unwell_11]

Hi Tere,

This is what is on the link:

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.

But, we are are not doing a multiple-hold scenario, nor am I getting inactive since I have these two fields turned on.

- Early Offer support for voice and video calls (insert MTP if needed)

- Send send-receive SDP in mid-call INVITE

It's weird though because "Send send-receive SDP in mid-call INVITE" SHOULD indicate an early offer for mid-call invites, but instead CUCM is doing a delayed offer.....

[Manish Prasad]

because "Send send-receive SDP in mid-call INVITE" SHOULD indicate an early offer for mid-call invites,- No it do not represent early offer or delayed offer , what it says if there is SDP in Re-Invite then the media attribute should be "a=sendrecv".

ITSP sends to CUBE a 200 OK with SDP but, has a=recvonly attribute in it -  At this point i think ITSP should send sendrecv in it attribute if its receiving a delayed offer Re-Invite from CUCM/CUBE.

Can you attach debug ccsip message for both the scenarios , i.e. with MTP checked and without MTP checked.

Thanks

Manish

[unwell_11]

FYI. After two or so weeks with TAC, it boiled down to changing one service parameter in CUCM. This was causing CUCM to send a=sendonly, instead of actually sending a=sendrcv.

[Nishant Savalia]

Hi ,

Could you please paste what was that service parameter that has been modified by TAC team for this resolution.