Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

One-way audio after call is put on hold

 

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!

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Hi,  Can you try the

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.

 

 

Regards, Tere. If you find this post helpful, please rate! :)
13 REPLIES
Cisco Employee

Hi,  Can you try the

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.

 

 

Regards, Tere. If you find this post helpful, please rate! :)
New Member

Thanks, Tere! I'll read

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!

Hi ,Could you please paste

Hi ,

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

Regards, Nishant Savalia
VIP Super Bronze

On CUCM go to System---

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

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Thank you Ayodeji,But i have

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

 

Regards, Nishant Savalia
VIP Super Bronze

Nishant,This is how the

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.

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Thank you for your response

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)?

 

 

Regards, Nishant Savalia
VIP Super Bronze

That parameter as far as I

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

 

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Once again thank you for

Once again thank you for explaination.

 

 

Regards, Nishant Savalia
New Member

Hi Tere,This is what is on

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.....

 

because "Send send-receive

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

New Member

FYI. After two or so weeks

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.

Hi ,Could you please paste

Hi ,

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

Regards, Nishant Savalia
4668
Views
28
Helpful
13
Replies
CreatePlease login to create content