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!

Regards,

Geoff

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

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

hth,

nick

Nick,

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.

Regards,

Geoff

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

h323

empty-capability

hth,

nick

No H.323 here Nick. It's all SIP.

I made an error when I said CVP won't play a message. It will, and it accepts DTMF and queues the call in the skill group. But when the agent goes ready, ICM reserves the agent but the call is not delivered.

I'll give it a shot though.

Regards,

Geoff

uys,

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.

Chris

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.

hth,

nick

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

HTH,

Chris

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.

hth,

nick