SIP Trunk - Audio Problem after Hold Resume

Unanswered Question
Dec 15th, 2008

Testing a SIP to SIP IP Trunking implementation with CUBE and came across an interesting problem. When a call is placed on hold and then resumed one side of the audio path breaks.

on an inbound call - no audio back to PSTN

on an outbound call - no audio back from PSTN

I was able to fix the inbound issue by enabling RFC 2543 Hold on the associated SIP Profile. Outbound calls still experience the same problem. I am running CUCM 6.1.2 and 12.4.20T on the CUBE router.



I have this problem too.
1 vote
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Nicholas Matthews Mon, 12/15/2008 - 11:00

For CUBE we see some odd problems from time to time, and sometimes upgrading to 20.T1 or 22T helps. It may be worth trying 12.4(22)T, as there are a ton of CUBE bugs fixed between 12.4(15)T and 22T. 20T has the majority of them, but there's a chance.

You will want to make sure this command is enabled for SIP-SIP IPIPGW

voice service voip


midcall-signalling passthru

Another thing that frequently solves CUBE problems is to require an MTP for the SIP trunk in CUCM.

Alternatively, you will want to check out the SIP SDP's to make sure that the media that is getting pass back and forth has reachability from where it's being sent to. You're not using NAT are you?

s.casper_2 Mon, 12/15/2008 - 13:28

Thanks! I will look into upgrading to 22T. We have midcall-signalling passthru configured. I was hoping not to use an MTP, supposably with 12.4.20T and SIP to SIP that was no longer a requirement but I will enable an MTP for the connection and see what happens.

Thanks for starting this thread. I have a similar problem with inbound SIP calls from the AT&T IP Toll Free service. My calls are not going directly to CUCM 6.1(3) - my calls are going to CVP 7.0(1) with a CUPS 6.0(2) as the SIP Proxy.

I have two problems - one minor and one major. When a call is delivered to an agent, and the agent puts the call on hold, the caller does not hear hold music (which is configured on the phone). That's the minor one. ;-)

When the call is retrieved, the voice path is not re-established - obviously, that's the major problem. We have a CUBE running 12.4(22)T.

With WireShark spanning the port to AT&T we see this exchange:

1. packet 1070 - cvp sends re-invite with session attribute: inactive.

2. packet 1076 - att sends ok with session attribute: inactive

3. packet 1078 - cvp sends re-invite with no sdp.

4. packet 1080 - att sends ok with session attribute: sendrcv

5. packet 1082 - cvp sends ack with session attribute: sendonly.

6. packets 1113, 1115, 1117 is a repeat of 1078, 1080, 1082.

7. packet 1136 - cvp sends a bye.


So why does cvp send "sendonly" in packet 1082?

If I run debug ccsip all and debug voice ccapi all I can see the problem. In fact, if I grep "stream direction" out of the logging buffer for a simple call (incoming call, rings at agent, agent answers, holds the call, retrieves the call, then drops). See attachment. Notice

src_callid = 1582, dest_callid = 1583, stream type = voice+dtmf, stream direction = SENDONLY

I have to disable 'midcall-signaling passthru" for CVP - CVP will simply not work without it. I've tested this a number of times.

I took the first piece of advice - and changed to a SIP Profile with RFC 2543 Hold checked, but no change.

Then I added MTP required to the SIP Trunk (the SIP Trunk goes to the SIP Proxy server) and the voice path was re-established on retrieve from hold. See attachment for the same sort of grep:

Surprisingly (well maybe not - those damn MTPs are funny), MOH now works back up the carrier.

Oh, I hate having to add MTPs. Especially since I am using a AS5350XM as the cube, and it has dspfarm limitations.

So thanks to nicmatth of Cisco for pointing me in the right direction. The solution is not what I had hoped for!





Nicholas Matthews Sat, 01/31/2009 - 14:42

Hi Geoff,


Midcall-signaling passthru is a mandatory command for SIP-SIP cube for midcall requests/responses.


What IOS version is this on?


For your questions about a=sendonly:

If the offerer wishes to only send media on a stream to its peer, it

MUST mark the stream as sendonly with the "a=sendonly" attribute. We

refer to a stream as being marked with a certain direction if a

direction attribute was present as either a media stream attribute or

a session attribute. If the offerer wishes to only receive media

from its peer, it MUST mark the stream as recvonly.


In this case, the stream is on hold, so we would be 'sendonly'.  I did a little looking into it, and a=sendonly should be nearly the same as a=inactive, except that inactive wouldn't be sending media. 


This part of RFC 3264 is of relevance:

If a stream is offered with a unicast address, the answer for that
stream MUST contain a unicast address. The media type of the stream
in the answer MUST match that of the offer.

If a stream is offered as sendonly, the corresponding stream MUST be
marked as recvonly or inactive in the answer. If a media stream is
listed as recvonly in the offer, the answer MUST be marked as
sendonly or inactive in the answer. If an offered media stream is
listed as sendrecv (or if there is no direction attribute at the
media or session level, in which case the stream is sendrecv by
default), the corresponding stream in the answer MAY be marked as
sendonly, recvonly, sendrecv, or inactive. If an offered media
stream is listed as inactive, it MUST be marked as inactive in the


Is there a difference in what CVP is sending to CUBE and what CUBE is sending your SIP provider?






All good stuff, and much of which I am familiar with - I read those sections of the RFC. I thank you for your insights.

The CUBE is running 12.4(22)T.

I don't mind the inactive and sendonly when the call goes on hold, as I expec that - what I don't like, and what the AT&T IP Toll Free Service does not like, is the "sendonly" ACK when the call is retrieved from hold.

This stops the voice path from being re-established after resume from hold. AT&T were adamant and I opened a TAC case to get Cisco's view - case 610600777.

I can tell you Nick, that if I put midcall-signaling passthru into the config, CVP will simply not work.

We did interoperability testing with the AT&T IP Toll Free Service direct to CUCM 6.1(3) and everything was sweet with that config - but with CVP, I could not make it work. It's a simple test I can make any time - if it's there, CVP will not play an announcement; take it out, and Bob's your uncle.

CVP is an unusual beast.



Nicholas Matthews Sat, 01/31/2009 - 16:24

Hi Geoff,


Took a look - you have H323-SIP which is an entirely different beast. 


For a lot of H323 supplementary services we find that MTPs are required.  I'm not so much on the Callmanager side, but I do know specifically for hold/transfer a MTP is normally required in H323.


You can try adding this command to see if it helps:


voice service voip






Chris Deren Fri, 03/06/2009 - 13:42


So should I be able to hear MOH without MTP or not?

Unless I enable MTP required on the SIP trunk I never get MOH for when agent puts the caller on hold, the call flow is very simple:

PSTN caller calls into CVP

Caller connects to agent

Agent puts caller on HOLD, no MOH

I tried it with multicast and unicast MOH and no luck, any idea? MTP usage on inbound calls is not an option as I have 100 vxml GWs all over the map and centralized MTP would kill me.


Nicholas Matthews Fri, 03/06/2009 - 14:07

Hi Chris,

What type of CUBE is it?

If it's H323-SIP you'll need MTP for supplementary services.

If it's SIP-SIP you will need 'early-offer forced' to do DO-EO interworking.

If it's H323-H323 you'll need 12.4(6)T or later to prevent needing MTP.



Chris Deren Fri, 03/06/2009 - 14:35

I do not have CUBE, my call is basic from PSTN-PRI to SIP based CVP.



Nicholas Matthews Fri, 03/06/2009 - 14:55

I would start a new thread - this was for CUBE.

Depending on how the invite process goes out, you will probably need MTP for MoH.

This is because there is a re-invite that happens with the MoH information, and if it doesn't have the SDP for the MoH the call fails.

You're able to get around this with CUBE, however.




This Discussion